Re: sourcing a sh file in zsh

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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 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.

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.

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".