Re: sourcing a sh file in zsh

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

Bart Schaefer wrote:
> We face a similar problem with the "sticky" emulation idea.  Let's
> suppose for purposes of illustration that "emulate -S" activates it.
> 
>     emulate -S sh -c 'debug() { set -vx }'
> 
> (Imagine the debug function is buried in, and used by, some lengthy
> piece of /bin/sh code that's being loaded.)  What happens when the
> debug function is executed?  An implicit LOCAL_OPTIONS breaks the
> intended behavior.

Although I see you can argue different ways, my view of this was that
this was "just tough".  An "emulate" of this kind specifically sets and
restores options.  If you want option propagation, you shouldn't mix
emulations.

What would be the intention of the code above, anyway?  I think the
answer is it's for debugging in sh emulation.  But then it belongs with
the code you're debugging, doesn't it?

emulate -S sh -c 'debug() { set -vx }
... sh code which calls debug ...
'

Now in *this* case, I think it's clear that the option should
propagate.  But I think that's OK... there's no "emulate" firewall
between the execution of debug and the code around.

To get this right (if that is right), we do need to be careful about how
we handle sticky emulation in functions:  if we're already in the
sticky emulation environment, as here, we don't want to set and restore
options around execution of functions defined in the same emulation
mode.  That would be regardless of which chunks of code they were
defined in, I think, otherwise we have a new type of firewall (between
code chunks rather than emulations) that we don't want.

In other words, your orignal code chunk would be fine if combined with
other code defined in another "emulate sh -c ..." chunk.  I think that's
all we need to get the job done.

-- 
Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/