Re: sourcing a sh file in zsh

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Jan 16,  7:59pm, Phil Pennock wrote:
}
} On 2009-01-16 at 10:29 -0800, Bart Schaefer wrote:
} > with the obvious meaning of "turn on sh emulation while sourcing" and
} > would otherwise behave like "source".  Might need a variant that has
} > the path-searching semantics of "." as well.
} 
} Isn't there a problem where a function is defined which assumes one set
} of semantics and the reset afterwards changes the semantics?

The reset after what?  This hypothetical feature?  Well, since it's
hypothetical, I'd have to say no, there isn't a problem, because if
the feature ever ceases to be hypothetical it should be implemented
so as to avoid that problem.

} Thus the reason why the entry points into completion set the relevant
} emulation options.

No, the reason the entry points into completion set the options is
because the functions in the completion system are written to expect
a specific set of options which are NOT the default for any of the
predefined emulations, so "emulate" isn't sufficient there.

If the constraints of (a) a function scope has been entered and (b)
"setopt localoptions" is in effect when the scope ends, then the
setopts after the scope is gone should be exactly the same as they
were before it began.  There is no bug I'm aware of where an option
is wrongly (not) restored after ending a localoptions scope.
 
} Really, we need to be able to have a function "remember" the options
} in effect at the time it was defined and restore them, without having
} to call emulate within them.

I think I begin to understand what you mean, but I think it's misguided.
There's no way for a function that's stored in script form as a file,
and then later sourced or autoloaded, to keep track of what options
were *intended* to be in effect at the time the file was stored to the
disk.  It can only know what options were in effect at the time that
the "source" command was executed, which doesn't solve the problem.

The closest you could get would be to add an option to zcompile to
have it prepend the compiled function definition with an appropriate 
setopts command.  This is already partly done by zcompile for the
special case of KSH_AUTOLOAD.

I see from your example that you suggest hacking this up semi-manually
by defining one function within another so that the outer function can
establish the option settings that the inner one should remember, but
that's only minimally helpful to the function writer and still doesn't
solve the original problem of variable scoping.

--