Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: sourcing a sh file in zsh



On 2009-01-26 at 12:21 +0000, Peter Stephenson wrote:
> 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.

You have made me very happy.  Thank you.

(the compressed Eprog stuff has always scared me away)

> 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.

Given the possible behaviours I presented in zsh-workers/26336, this
seems problematic.  Either the new option value set is read-only, so
that fails, or the setopt in the zsh callback function change the values
back inside the sh area.

I think that the best thing to do would be to restore the option values
from before crossing that emulate boundary, unless the zsh function
itself has an emulate boundary.

I think that I shall have to write tests covering these cases and post
them before I write code to implement it -- anything else is too fraught
with peril.

-Phil



Messages sorted by: Reverse Date, Date, Thread, Author