From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20652 invoked from network); 26 Jan 2009 12:21: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.3 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; 26 Jan 2009 12:21:51 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 29127 invoked from network); 26 Jan 2009 12:21:44 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 26 Jan 2009 12:21:44 -0000 Received: (qmail 1994 invoked by alias); 26 Jan 2009 12:21:38 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26447 Received: (qmail 1977 invoked from network); 26 Jan 2009 12:21:37 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 26 Jan 2009 12:21:37 -0000 Received: from cluster-d.mailcontrol.com (cluster-d.mailcontrol.com [85.115.60.190]) by bifrost.dotsrc.org (Postfix) with ESMTPS id F2F5F80271F0 for ; Mon, 26 Jan 2009 13:21:33 +0100 (CET) Received: from cameurexb01.EUROPE.ROOT.PRI ([193.128.72.68]) by rly02d.srv.mailcontrol.com (MailControl) with ESMTP id n0QCLWrj000934 for ; Mon, 26 Jan 2009 12:21:32 GMT Received: from news01 ([10.103.143.38]) by cameurexb01.EUROPE.ROOT.PRI with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Jan 2009 12:21:10 +0000 Date: Mon, 26 Jan 2009 12:21:04 +0000 From: Peter Stephenson To: zsh-workers@sunsite.dk Subject: Re: sourcing a sh file in zsh Message-ID: <20090126122104.0e3013ba@news01> In-Reply-To: <20090126061819.GB54012@redoubt.spodhuis.org> References: <200901161939.54651.arvidjaar@newmail.ru> <090116102934.ZM22119@torch.brasslantern.com> <200901241859.30029.arvidjaar@gmail.com> <20090124173836.64403fdc@pws-pc> <090124152643.ZM24163@torch.brasslantern.com> <20090125213946.4c868e74@pws-pc> <20090126061819.GB54012@redoubt.spodhuis.org> Organization: CSR X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.8; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jan 2009 12:21:10.0132 (UTC) FILETIME=[923EA340:01C97FB0] X-Scanned-By: MailControl A_08_51_00 (www.mailcontrol.com) on 10.68.0.112 X-Virus-Scanned: ClamAV 0.92.1/8903/Mon Jan 26 11:43:08 2009 on bifrost X-Virus-Status: Clean On Sun, 25 Jan 2009 22:18:19 -0800 Phil Pennock wrote: > On 2009-01-25 at 21:39 +0000, Peter Stephenson wrote: > > On Sat, 24 Jan 2009 15:26:43 -0800 > > Bart Schaefer wrote: > > > } There's still the issue of retaining the emulation mode for functions > > > } defined in that mode; I agree we really ought to tackle that to make > > > } the new functionality properly useful. I expect Bart has ideas on the > > > } next step; how far will we need to go? > > > > > > I refer you to workers/26336 where Phil makes some comments about how > > > he'd modify the wordcode to handle this. > > > > I can't offhand think of a case that needs to be that complicated. > > Either you run a chunk of code using "emulate", or you have a shell > > function, possibly defined in such a chunk, where sticking the flags in > > the shfunc structure for future reference is good enough. Where would > > you need something more than that? > > I need to sit down and trace out the mechanics of the existing code to > understand the ways that invocation of a function can occur. What I > wrote was: > > ----------------------------8< cut here >8------------------------------ > 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). > ----------------------------8< cut here >8------------------------------ > > If I was wrong, and all function invocation goes via the shfunc entries, > then (a) that's much easier and (b) I'm very happy. 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. 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. (You *could* mark that other function as "always run in zsh emulation" with suitable use of "emulate" during its definition or (TBD) by manipulating flags, I suppose--that ought to be supported, I don't see why we should exclude native emulation from the system.) -- Peter Stephenson Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070