Re: sourcing a sh file in zsh

[Peter Stephenson <pws@xxxxxxx>]

On Sun, 25 Jan 2009 22:18:19 -0800
Phil Pennock <zsh-workers+phil.pennock@xxxxxxxxxxxx> wrote:
> On 2009-01-25 at 21:39 +0000, Peter Stephenson wrote:
> > On Sat, 24 Jan 2009 15:26:43 -0800
> > Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> > > } There's still the issue of retaining the emulation mode for functions
> > > } defined in that mode; I agree we really ought to tackle that to make
> > > } the new functionality properly useful. I expect Bart has ideas on the
> > > } next step; how far will we need to go?
> > > 
> > > I refer you to workers/26336 where Phil makes some comments about how
> > > he'd modify the wordcode to handle this.
> > 
> > I can't offhand think of a case that needs to be that complicated.
> > Either you run a chunk of code using "emulate", or you have a shell
> > function, possibly defined in such a chunk, where sticking the flags in
> > the shfunc structure for future reference is good enough.  Where would
> > you need something more than that?
> 
> I need to sit down and trace out the mechanics of the existing code to
> understand the ways that invocation of a function can occur.  What I
> wrote was:
> 
> ----------------------------8< cut here >8------------------------------
> The problem is how to decide if a function needs a new option; I haven't
> looked too closely but I believe that functions are invoked from each
> other directly via the Eprog code, rather than dispatch through the
> shfunctab shfunc entries, so it's not viable to go via extending shfunc
> (pity).
> ----------------------------8< cut here >8------------------------------
> 
> If I was wrong, and all function invocation goes via the shfunc entries,
> then (a) that's much easier and (b) I'm very happy.

For the case of shell functions, the Eprog is always used via the
placeholder in the Shfunc structure, so far as I know.  I don't see how it
could be otherwise---as all function execution by name goes through
doshfunc(), even if you copy the corresponding Eprog for some reason, it's then
no longer a shell function and the emulation guarantee no longer applies.
doshfunc() was changed a few months ago so we always pass in the Shfunc, so
I don't think there's a difficulty here.

One other point to clear up: what happens when a function defined to be in
sh emulation calls a function that isn't (and that would therefore usually
expect the user's usual options to be in effect when it starts).  I think
the answer is "nothing special"---we are not attempting to guarantee option
settings for all functions, simply to allow a complete set of code to
operate in emulation, and if you're mixing code in this way it's "caveat
executor".  So if you're calling out to a non-sh function, you're thrown
back on the standard zsh answer---if you want to sanitize the options, you
do it explicitly within the function (typically with "emulate -L").  I
don't think that's controversial, I just wanted to be clear about it.

(You *could* mark that other function as "always run in zsh emulation" with
suitable use of "emulate" during its definition or (TBD) by manipulating
flags, I suppose--that ought to be supported, I don't see why we should
exclude native emulation from the system.)

-- 
Peter Stephenson <pws@xxxxxxx>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070