Re: sourcing a sh file in zsh

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Jan 27,  1:51am, Richard Hartmann wrote:
} Subject: Re: sourcing a sh file in zsh
}
} On Tue, Jan 27, 2009 at 00:07, Phil Pennock
} <zsh-workers+phil.pennock@xxxxxxxxxxxx> wrote:
} 
} > What I do like with the
} > setopt approach is that there's a way for zsh to test if this is
} > currently the case.

This does raise an interesting edge case.  What happens if one invokes
"eumulate" (without the "-c") inside a sticky emulation context?  Does
it turn off the sticky, or does the new emulation become sticky?

This question needs to be answered whether or not stickiness is
implemented as a setopt.  My inclination is to say that it turns off
the sticky, but in that case "emulate -L" ought to restore stickyness
again.

Maybe the right way to do this is with a stack of emulation contexts.
Using -L or -c creates one, otherwise emulate modifies the current one.
That would parallel the LOCAL_OPTIONS semantics ... and I suppose may
be an argument in favor of adding a setopt, though I'm still leery of
that for other reasons.

} > Eg, for bash/zsh portability, you could do:
} >  if [[ -n $ZSH_VERSION && -o sticky_options ]]
} > since both support [[ conditional ]] and both support -o as a unary
} > prefix test (both using it for testing shell options).
} 
} emulate could simply set $ZSH_STICKY to 'sh' or something

We've already made "emulate" with no arguments return the current
emulation mode.  Perhaps it could append the -c when sticky emulation
is in effect.  That would make [[ $(emulation) = zsh ]] a bit less
useful ... you'd have to do [[ $(emulation) = zsh* ]] ... hmm.