From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20056 invoked from network); 12 Feb 2009 02:23:51 -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; 12 Feb 2009 02:23:51 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 85112 invoked from network); 12 Feb 2009 02:23:38 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 12 Feb 2009 02:23:38 -0000 Received: (qmail 12276 invoked by alias); 12 Feb 2009 02:23:32 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26559 Received: (qmail 12265 invoked from network); 12 Feb 2009 02:23:31 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 12 Feb 2009 02:23:31 -0000 Received: from vms173015pub.verizon.net (vms173015pub.verizon.net [206.46.173.15]) by bifrost.dotsrc.org (Postfix) with ESMTP id D8502802720F for ; Thu, 12 Feb 2009 03:23:18 +0100 (CET) Received: from torch.brasslantern.com ([96.238.220.215]) by vms173015.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KEX006EOLANE9T0@vms173015.mailsrvcs.net> for zsh-workers@sunsite.dk; Wed, 11 Feb 2009 20:23:16 -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 n1C2N7fL009879 for ; Wed, 11 Feb 2009 18:23:08 -0800 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id n1C2N7GP009878 for zsh-workers@sunsite.dk; Wed, 11 Feb 2009 18:23:07 -0800 From: Bart Schaefer Message-id: <090211182307.ZM9877@torch.brasslantern.com> Date: Wed, 11 Feb 2009 18:23:06 -0800 In-reply-to: <20090211202840.000b37aa@pws-pc> Comments: In reply to Peter Stephenson "Re: PATCH: sticky emulation" (Feb 11, 8:28pm) References: <18952.1234307021@pws-pc> <090210191804.ZM7110@torch.brasslantern.com> <20090211202840.000b37aa@pws-pc> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@sunsite.dk (Zsh hackers list) Subject: Re: PATCH: sticky emulation MIME-version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.92.1/8981/Thu Feb 12 01:28:11 2009 on bifrost X-Virus-Status: Clean On Feb 11, 8:28pm, Peter Stephenson wrote: } } I'll submit the lot and it can be modified later if necessary. Documentation nit: My info-viewer and my emacs both display the list of emulate rules like so: The documentation above is typically sufficient for the intended purpose of executing code designed for other shells in a suitable environment. More detailed rules follow. 1. The sticky emulation environment provided by `emulate SHELL -c' is identical to that provided by entry to a function marked for sticky emulation as a consequence of being defined in such an environment. Hence, for example, the sticky emulation is inherited by subfunctions defined within functions with sticky emulation. 2. No change of options takes place on entry to or exit from functions that are not marked for sticky emulation, other than those that would normally take place, even if those functions are called within sticky emulation. (and so on with the floating numbers one line up and one character too far "outdented"). I compiled this and started poking around and immediately encountered an interesting side-effect. Consider the function "allopt" which is autoloaded and dumps out a list of the options and their states. Starting from % emulate sh -c "allopt" (list of options appears as expected, with "sh" states) zsh: allopt: function not defined by file OK, clearly allopt should be getting "autoload -z" treatment. (Aside: Does the doc really not explain "autoload -z" anywhere? Have I just missed it?) On reflection the rest of what follows is exactly as I should have expected it to be, but having rambled on writing it all down I'm going to send it anyway. Exit and start a new shell, try this: % emulate sh -c "ao() { allopt; }" % ao (list of options appears as expected, with "sh" states) zsh: allopt: function not defined by file % allopt (list of options appears with zsh states) Exit and start again: % autoload -z allopt % emulate sh -c "allopt" (list of options appears as expected, with "sh" states) % allopt (list of options appears with zsh states) Exit and start again: % unfunction allopt % emulate sh -c "autoload -z allopt; allopt" (list of options appears as expected, with "sh" states) % allopt (list of options appears with zsh states) So there's no way to cause an autoloaded function to acquire sticky emulation, which is what's meant by "No special handling for ... autoload." --