On 30 of January 2009 07:25:01 Bart Schaefer wrote:
> Getting back to this a bit later ...
>
> On Jan 26, 7:49pm, Andrey Borzenkov wrote:
> } Subject: Re: sourcing a sh file in zsh
> }
> } On 26 0x044F0x043D0x04320x04300x04400x044F 2009 10:51:21 Bart
> Schaefer wrote: } >
> } > } emulate sh -c "setopt sticky_emulation; source
> } > /my/shell/library.sh"
> } >
> } > This doesn't work, does it?
> }
> } Right, because this option does not exist. Or do you mean something
> } else?
>
> I meant I didn't think it would do what you intended, but:
>
> } > "emulate sh -c ..." does not imply a
> } > full setopts reset at the end of the eval, only a reset of the
> } > emulation mode.
> }
> } It does. This is exactly what LOCAL_OPTIONS does as well.
>
> Obviously I understand that's what LOCAL_OPTIONS does, but I never
> meant for that to be what "emulate" did. Apparently I misread your
> patch.
>
I apologize for not being clear enough as well.
Discussion actually started with the this code (not exactly, but):
function run_on_sh_mode {
emulate -L sh
$*
}
So I intended emulate -c to be replacement for above without possible
scoping issues (because e.g. startup scripts here do set quite a lot of
variables).
> I expected an approximate equivalence between
>
> emulate sh -c "echo foo"
>
> and
>
> {
> emu=$(emulate)
> emulate sh
> eval "echo foo"
> } always {
> emulate $emu
> }
>
> I *didn't* expect an equivalence to function scopes with respect to
> any setopts that aren't normally affected by changing the emulation.
>
This is doable. I did not quite like it because my primary intention was
to run foreign code. In which case I definitely would not like this code
by accident change shell behaviour. So it is sort of sandbox.
Another observation that my intended usage was almost exclusively
"emulate -R"; in which case to revert this you have to reset *all*
options anyway.
> Having said that, however, I'm left undecided as to whether it really
> makes any difference. I admit there are cases where I wished I had
> a LOCAL_OPTIONS scope and *not* a "local" parameter scope, a result
> for which this form of emulate can be abused.
>
I think we need to sort this out before usage sticks.
So let's consider what we get
emulate -L -c "command"
implicitly set LOCAL_OPTIONS before executing command
emulate [-R] -c "command"
implicitly do "emulate [-R] oldemulation" after executing command
Do I miss something? Is it what you intend?
> However, I do think that (if the implementation remains as-is) the
> documentation needs to be clearer that the *entire* setopt context is
> restored. Currently it says only that "Emulation will be restored".
I will update it.
Attachment:
signature.asc
Description: This is a digitally signed message part.