Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: sourcing a sh file in zsh
- X-seq: zsh-workers 26458
- From: Peter Stephenson <pws@xxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: sourcing a sh file in zsh
- Date: Tue, 27 Jan 2009 09:50:43 +0000
- In-reply-to: <20090126231630.GB18017@xxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <BD9D2405-AD6A-4336-9C8A-85149165B6B8@xxxxxxxxx> <200901161939.54651.arvidjaar@xxxxxxxxxx> <090116102934.ZM22119@xxxxxxxxxxxxxxxxxxxxxx> <200901241859.30029.arvidjaar@xxxxxxxxx> <20090124173836.64403fdc@pws-pc> <090124152643.ZM24163@xxxxxxxxxxxxxxxxxxxxxx> <20090125213946.4c868e74@pws-pc> <20090126061819.GB54012@xxxxxxxxxxxxxxxxxxxx> <20090126122104.0e3013ba@news01> <20090126231630.GB18017@xxxxxxxxxxxxxxxxxxxx>
Phil Pennock wrote:
> > One other point to clear up: what happens when a function defined to be in
> > sh emulation calls a function that isn't (and that would therefore usually
> > expect the user's usual options to be in effect when it starts). I think
> > the answer is "nothing special"---we are not attempting to guarantee option
> > settings for all functions, simply to allow a complete set of code to
> > operate in emulation, and if you're mixing code in this way it's "caveat
> > executor". So if you're calling out to a non-sh function, you're thrown
> > back on the standard zsh answer---if you want to sanitize the options, you
> > do it explicitly within the function (typically with "emulate -L"). I
> > don't think that's controversial, I just wanted to be clear about it.
>
> Given the possible behaviours I presented in zsh-workers/26336, this
> seems problematic. Either the new option value set is read-only, so
> that fails, or the setopt in the zsh callback function change the values
> back inside the sh area.
>
> I think that the best thing to do would be to restore the option values
> from before crossing that emulate boundary, unless the zsh function
> itself has an emulate boundary.
This is the road I really don't want to go down. The system is to
provide a delimited execution environment where you can run code in an
emulation. It is not to track every change of option at every stage in
the process. Having the behaviour change bodily at explicit "emulate"s
and at functions marked for emulation should be good enough, and is much
more obvious behaviour than trying to insert magic conversion points.
If you call to a function that doesn't fit in that environment you
should make your own arrangements.
I don't see why options should ever be read-only, and I don't see why
executing a function that changes option values in the parent should be
forbidden from doing so, given that this is explicitly supported zsh
behaviour. You always have enough rope to hang yourself with a
shell---if you don't want native zsh behaviour seeping out, don't use a
native zsh function, or be explicit with the "emulate -L"s.
--
Peter Stephenson <pws@xxxxxxx> Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070
Messages sorted by:
Reverse Date,
Date,
Thread,
Author