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.