From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9535 invoked from network); 17 Jan 2009 05:01:10 -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:01:10 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 19487 invoked from network); 17 Jan 2009 05:01:04 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 17 Jan 2009 05:01:04 -0000 Received: (qmail 5001 invoked by alias); 17 Jan 2009 05:00:57 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26334 Received: (qmail 4991 invoked from network); 17 Jan 2009 05:00:57 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 17 Jan 2009 05:00:57 -0000 Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by bifrost.dotsrc.org (Postfix) with ESMTP id 1FBED809A128 for ; Sat, 17 Jan 2009 06:00:52 +0100 (CET) Received: from torch.brasslantern.com ([96.238.220.215]) by vms173005.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0KDL007SLN9ABAA3@vms173005.mailsrvcs.net> for zsh-workers@sunsite.dk; Fri, 16 Jan 2009 23:00:51 -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 n0H50jjB022625 for ; Fri, 16 Jan 2009 21:00:46 -0800 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id n0H50jMA022624 for zsh-workers@sunsite.dk; Fri, 16 Jan 2009 21:00:45 -0800 Date: Fri, 16 Jan 2009 21:00:42 -0800 From: Bart Schaefer Subject: Re: sourcing a sh file in zsh In-reply-to: <20090117035923.GA64953@redoubt.spodhuis.org> To: zsh-workers@sunsite.dk Message-id: <090116210045.ZM22623@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> Comments: In reply to Phil Pennock "Re: sourcing a sh file in zsh" (Jan 16, 7:59pm) X-Virus-Scanned: ClamAV 0.92.1/8873/Sat Jan 17 04:33:31 2009 on bifrost X-Virus-Status: Clean 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. } Thus the reason why the entry points into completion set the relevant } emulation options. No, the reason the entry points into completion set the options is because the functions in the completion system are written to expect a specific set of options which are NOT the default for any of the predefined emulations, so "emulate" isn't sufficient there. If the constraints of (a) a function scope has been entered and (b) "setopt localoptions" is in effect when the scope ends, then the setopts after the scope is gone should be exactly the same as they were before it began. There is no bug I'm aware of where an option is wrongly (not) restored after ending a localoptions scope. } Really, we need to be able to have a function "remember" the options } in effect at the time it was defined and restore them, without having } to call emulate within them. 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. --