Re: sourcing a sh file in zsh

[Peter Stephenson <p.w.stephenson@ntlworld.com>]

On Sat, 24 Jan 2009 18:59:27 +0300
Andrey Borzenkov <arvidjaar@gmail.com> wrote:
> On 16 января 2009 21:29:34 Bart Schaefer wrote:
> > Another possibility would be to extend the "emulate" command into a
> > precommand modifier sort of thing, where arguments following the name
> > of the emulation are treated as a command to execute.  Perhaps
> > require another option to make this active, to avoid any compatibily
> > issue.
> >
> >   emulate -LRE srh source file.sh
> >
> 
> What about the following patch. It simply eval's any code after setting 
> requested emulation. As a bonus it prints current emulation if no argument 
> is specified. Neither should be of compatibility issues as emulate always 
> allowed exactly one argument.
> 
> Comments?

Certainly looks like it's going the right way---as you say there
shouldn't be any compatibility issues, so we can probably roll it out
and see what happens.  You need quotes for defining functions in an
emulation, or to creating a separate file.  Hmm... I wonder if we should
allow code from stdin for things like:

emulate -LRE sh <<HERE
function foo {
  ...
}
HERE

?

It would be good to get some tests, even ideas for tests, to tease out
any subtle cases where things are/aren't being set incorrectly.


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?  The simplest idea would be for shell
functions to get a flag giving the emulation mode (with the default
being don't change emulation as now); we could set a global flag while
the "emulate" eval is being run that the mode flag for a function needs
to be inherited from the emulation.  Would this need another flag to
"emulate", or would it be good enough always to inherit the emulation
mode when "emulate -E" is in effect?  I don't think functions should
*always* inherit the emulation because it changes the current behaviour
too much---we would be resetting a whole load of options before every
function call.

I would guess we don't want to apply it to autoloaded functions which
already have their own rules.  We can also add commands to tweak the
emulation mode for individual functions, but that can be done
separately.

We do need to be quite clear on the rules to avoid tying ourselves in
knots with things like "emaulate -LRE sh autoload foo".  "foo", in my
interpretation, would not inherit sh behaviour here.  I think nested
"emulate"s should be unproblematic, however.

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