Re: sourcing a sh file in zsh

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Jan 25, 11:40am, Andrey Borzenkov wrote:
}
} [...] you are right, implying -L makes
} both code and documentation simpler. [...]
} 
} I personally would flag -LE as error then for the same reason as well
} as do not confuse user who reads manuals. Let -L just always set
} LOCAL_OPTIONS.

Under the assumption that we carry through and cause the emulation
mode or possibly other options to be automatically saved/restored
for any functions defined in the emulate scope, the effect is going
to be quite similar to that of setting LOCAL_OPTIONS globally.

Consequently I think it makes little difference whether -L/-c are
mutually exclusive; I'm OK with it either way.
 
} 	emulate sh -c "some command" arg1 arg2 ...
} 
} is valid (it is with shell, is not it?)  This could be added later if 
} someone finds usage case.

That's an interesting one.  Yes, I could envision a case where one may
want to have a local $argv in the emulate scope.
 
} Yes, I am more and more inclined to make it "-c ..."  ... OK to commit?

I think so.

On Jan 25, 11:56am, Andrey Borzenkov wrote:
}
} On 25 Jan 2009 02:26:43 Bart Schaefer wrote:
} > On Jan 24,  5:38pm, Peter Stephenson wrote:
} > } Subject: Re: sourcing a sh file in zsh
} > }
} > } You need quotes for defining functions in an
} > } emulation, or to creating a separate file.
} >
} > Yeah, that was one of my reasons for pondering making it a reserved
} > word or the like.
} 
} If you are defining function in a *zsh* script, why not simply define it 
} as *zsh* function?

    emulate sh
    # ...
    emulate zsh -c "${$(<<\HERE
    function ...
    HERE)}"
    # ...

Yeah, that's a bit contrived.

--