Zsh Mailing List Archive
Messages sorted by:
Re: sourcing a sh file in zsh
- X-seq: zsh-workers 26455
- From: Phil Pennock <zsh-workers+phil.pennock@xxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: sourcing a sh file in zsh
- Date: Mon, 26 Jan 2009 15:16:31 -0800
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=d200807; d=spodhuis.org; h=Received:Date:From:To:Subject:Message-ID:Mail-Followup-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=zHNCuCtW5RcI9N87htclZn8S+KF3qWFrYXe/bi1AXUX76VDuKWksW/qXJUvVFoqUVWMi6Q2RqX9R2SLFAC7xtc4oGsXko50OkgAtDX8FezlgXaNLgd663xmEdTjQ/sX/9Xhx6+Nz0hCsJr5scpWDeXQ05vOd6WQ8GL1DpnjF3mw=;
- In-reply-to: <20090126122104.0e3013ba@news01>
- Mail-followup-to: zsh-workers@xxxxxxxxxx
- 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>
On 2009-01-26 at 12:21 +0000, Peter Stephenson wrote:
> For the case of shell functions, the Eprog is always used via the
> placeholder in the Shfunc structure, so far as I know. I don't see how it
> could be otherwise---as all function execution by name goes through
> doshfunc(), even if you copy the corresponding Eprog for some reason, it's then
> no longer a shell function and the emulation guarantee no longer applies.
> doshfunc() was changed a few months ago so we always pass in the Shfunc, so
> I don't think there's a difficulty here.
You have made me very happy. Thank you.
(the compressed Eprog stuff has always scared me away)
> 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.
I think that I shall have to write tests covering these cases and post
them before I write code to implement it -- anything else is too fraught
Messages sorted by: