From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4663 invoked from network); 17 Jan 2009 05:56:15 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 17 Jan 2009 05:56:15 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 34675 invoked from network); 17 Jan 2009 05:56:09 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 17 Jan 2009 05:56:09 -0000 Received: (qmail 226 invoked by alias); 17 Jan 2009 05:56:05 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26336 Received: (qmail 215 invoked from network); 17 Jan 2009 05:56:04 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 17 Jan 2009 05:56:04 -0000 Received: from mx.spodhuis.org (redoubt.spodhuis.org [193.202.115.177]) by bifrost.dotsrc.org (Postfix) with ESMTPS id 03C9F80271F0 for ; Sat, 17 Jan 2009 06:55:59 +0100 (CET) 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=CWtkdVuQGz9RwKODaoxxAULnWDSuy9MdhiifZP9FZnIwk5WWEIlWjA4wnXJwkiIetFEhkWwQZ2IpFP3WMrJb+feLHXww8JAg8WARDqDYwpL+qNYMjmuWgYRlngbgYULI9hVKGbaWBbDYBpYOrE2EcxqMDNbdoeV+K3Pu1WjDCQw=; Received: by smtp.spodhuis.org with local id 1LO4A3-000Fn5-Rm; Sat, 17 Jan 2009 05:55:59 +0000 Date: Fri, 16 Jan 2009 21:55:59 -0800 From: Phil Pennock To: zsh-workers@sunsite.dk Subject: Re: sourcing a sh file in zsh Message-ID: <20090117055559.GA60339@redoubt.spodhuis.org> Mail-Followup-To: zsh-workers@sunsite.dk References: <090116075615.ZM21871@torch.brasslantern.com> <200901161939.54651.arvidjaar@newmail.ru> <090116102934.ZM22119@torch.brasslantern.com> <20090117035923.GA64953@redoubt.spodhuis.org> <090116210045.ZM22623@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <090116210045.ZM22623@torch.brasslantern.com> X-Virus-Scanned: ClamAV 0.92.1/8873/Sat Jan 17 04:33:31 2009 on bifrost X-Virus-Status: Clean On 2009-01-16 at 21:00 -0800, Bart Schaefer wrote: > On Jan 16, 7:59pm, Phil Pennock wrote: > } On 2009-01-16 at 10:29 -0800, Bart Schaefer wrote: > } > with the obvious meaning of "turn on sh emulation while sourcing" and > } > would otherwise behave like "source". Might need a variant that has > } > the path-searching semantics of "." as well. > } > } Isn't there a problem where a function is defined which assumes one set > } of semantics and the reset afterwards changes the semantics? > > The reset after what? This hypothetical feature? Well, since it's > hypothetical, I'd have to say no, there isn't a problem, because if > the feature ever ceases to be hypothetical it should be implemented > so as to avoid that problem. Okay, and that raises the issue of reset and options from outside a function needing to be retained as part of the function definition. > I think I begin to understand what you mean, but I think it's misguided. > There's no way for a function that's stored in script form as a file, > and then later sourced or autoloaded, to keep track of what options > were *intended* to be in effect at the time the file was stored to the > disk. It can only know what options were in effect at the time that > the "source" command was executed, which doesn't solve the problem. > > The closest you could get would be to add an option to zcompile to > have it prepend the compiled function definition with an appropriate > setopts command. This is already partly done by zcompile for the > special case of KSH_AUTOLOAD. > > I see from your example that you suggest hacking this up semi-manually > by defining one function within another so that the outer function can > establish the option settings that the inner one should remember, but > that's only minimally helpful to the function writer and still doesn't > solve the original problem of variable scoping. The example in my notes is probably not the best; it's based on an assumption that loading external non-zsh files is best done using a function which sets the options wanted and sources, to restore the state needed afterwards, but a zsource would be equivalent. The problem I have is some utility libraries which are written with bash as an assumption and then justified to the zsh-users with "hey, they work with zsh too" because they, oh, setopt sh_word_split. I don't want my normal shell contaminated with that garbage -- I like zsh's behaviour. The idea is basically just "set this option and functions have an implicit emulate at the start which sets the options in effect at the time the function was defined", to let me source utility libraries and have sh_word_split turned on for them (and probably ksh_arrays too) without having it effect everything else I do in the shell. The front-end interface file, which sources everything else and which has shell-specific shims to "handle" zsh can then have a zsh version-check to just instead catch the value of the options, setopt inherit_options and the others, and then restore options after it's done pulling in the other files. I can easily get updates made to the interface, but there's no way that shell-specific stuff will get into every function defined across all the other files -- #ifdef littering is bad, in any language. So, the problem is probably my lack of understanding of various areas of internals I haven't previously touched; my rought plan is: * use copies of opts, which can be memcpy'd around (since it's a static variable and making it a variable pointer might be more intrusive; wrap it in an API and this can be changed if it's easier to make opts a pointer which can be moved) * minimally, when inherit_options is in effect, bar changes to restricted, interactive, privileged, etc * setopt inherit_options creates a copy of opts; either: (a) this is read-only, no options changed within inherit scope, so set things up carefully first; (b) all functions defined within the scope of one instance of setting inherit_options share a unified option space and changes in one affect all others * At time of function call, see if crossing a boundary between values of inherit_options; if so, put the pointer to the current opts into a new item in struct funcstack; when unwinding stack, if the restoreopts item is non-NULL, restore it. The problem is how to decide if a function needs a new option; I haven't looked too closely but I believe that functions are invoked from each other directly via the Eprog code, rather than dispatch through the shfunctab shfunc entries, so it's not viable to go via extending shfunc (pity). So I'm thinking an Eprog WC_OPTSPACE instruction which can be inserted at some point arounf execfuncdef() time, which is stored with a value which points to the opts value to be put into effect and which, when encountered, adjusts the current funcstack entry to hold the current opts before replacing opts with the one referenced in the Eprog. Okay, how many fundamental misunderstandings on my part have I just exposed? -Phil