From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17756 invoked from network); 17 Jan 2009 20:15:42 -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 20:15:42 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 76412 invoked from network); 17 Jan 2009 20:15:37 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 17 Jan 2009 20:15:37 -0000 Received: (qmail 15235 invoked by alias); 17 Jan 2009 20:15:30 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26351 Received: (qmail 15219 invoked from network); 17 Jan 2009 20:15:29 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 17 Jan 2009 20:15:29 -0000 Received: from vms173007pub.verizon.net (vms173007pub.verizon.net [206.46.173.7]) by bifrost.dotsrc.org (Postfix) with ESMTP id 20CCC80271F0 for ; Sat, 17 Jan 2009 21:15:24 +0100 (CET) Received: from torch.brasslantern.com ([96.238.220.215]) by vms173007.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0KDM0029PTINN6L7@vms173007.mailsrvcs.net> for zsh-workers@sunsite.dk; Sat, 17 Jan 2009 14:13:40 -0600 (CST) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id n0HKF1F8008942 for ; Sat, 17 Jan 2009 12:15:02 -0800 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id n0HKF1hT008941 for zsh-workers@sunsite.dk; Sat, 17 Jan 2009 12:15:01 -0800 Date: Sat, 17 Jan 2009 12:15:01 -0800 From: Bart Schaefer Subject: Re: sourcing a sh file in zsh In-reply-to: <20090117055559.GA60339@redoubt.spodhuis.org> To: zsh-workers@sunsite.dk Message-id: <090117121501.ZM8940@torch.brasslantern.com> MIME-version: 1.0 X-Mailer: OpenZMail Classic (0.9.2 24April2005) Content-type: text/plain; charset=us-ascii 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> <20090117055559.GA60339@redoubt.spodhuis.org> Comments: In reply to Phil Pennock "Re: sourcing a sh file in zsh" (Jan 16, 9:55pm) X-Virus-Scanned: ClamAV 0.92.1/8873/Sat Jan 17 04:33:31 2009 on bifrost X-Virus-Status: Clean On Jan 16, 9:55pm, Phil Pennock wrote: } Subject: Re: sourcing a sh file in zsh } } 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. OK, I think I get it now, and sorry for being a bit dense before. You are talking about a situation where: - There is a script file of some sort, meant to be read by "source". - That script file doesn't just do something once (like assign to a bunch of environment variables) and go away; instead, it defines shell functions that are intended to be used interactively later. - Those shell functions make the reasonable assumption that if the function defintion was parsed by, e.g., a POSIX-compatible shell, then the shell will still be POSIX-compatible when the function is actually run. Leaving aside for the moment the fact that it's entirely possible to parse a function definition with NO_SH_WORD_SPLIT that won't then work without SH_WORD_SPLIT, so "the setopts in effect at parse time" might not be a valid representation of "the setopts needed at run time", I agree that it might be useful to be able to cause a specific set of options to become set before entry to a given function. This gets very tricky, however, when applied to functions that are actually designed for zsh. An implicit preset of options implies an implicit restore later, but a zsh function which deliberately does NOT "setopt localoptions" is expecting any setopt it executes to persist after the function exits. It'll be complicated to keep track of which options should be restored because of implicit preset, and which ones should not be restored because of explicit change. Regardless I don't think we'd want to do this as yet another setopt. It's potential can of worms along the lines of ALL_EXPORT, in that one can end up accidentally applying a specific option context to a function definition where one didn't (or shouldn't) mean to do so. I'd lean toward something that works like the "emulation" global, which is still localized to function scope but which is changable only by the "emulate" command. Combined with allowing "emulate" create a scope and run a command in that scope, is there anything else you'd need? PWS, any comment on how difficult it would be to extend "emulate" in this way? Would it require promoting emulate to a keyword? } 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. This part sounds fine to me, but I've never been the expert on Eprogs.