From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16273 invoked from network); 27 Jan 2009 09:53:35 -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; 27 Jan 2009 09:53:35 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 5800 invoked from network); 27 Jan 2009 09:53:30 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 27 Jan 2009 09:53:30 -0000 Received: (qmail 25625 invoked by alias); 27 Jan 2009 09:53:24 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26458 Received: (qmail 25615 invoked from network); 27 Jan 2009 09:53:24 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 27 Jan 2009 09:53:24 -0000 Received: from cluster-g.mailcontrol.com (cluster-g.mailcontrol.com [208.87.233.190]) by bifrost.dotsrc.org (Postfix) with ESMTPS id F16EE80271F0 for ; Tue, 27 Jan 2009 10:53:20 +0100 (CET) Received: from cameurexb01.EUROPE.ROOT.PRI ([193.128.72.68]) by rly20g.srv.mailcontrol.com (MailControl) with ESMTP id n0R9pVgn026482 for ; Tue, 27 Jan 2009 09:53:15 GMT Received: from news01.csr.com ([10.103.143.38]) by cameurexb01.EUROPE.ROOT.PRI with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Jan 2009 09:50:44 +0000 Received: from news01.csr.com (localhost.localdomain [127.0.0.1]) by news01.csr.com (8.14.2/8.13.4) with ESMTP id n0R9oiKS016652 for ; Tue, 27 Jan 2009 09:50:44 GMT Received: from csr.com (pws@localhost) by news01.csr.com (8.14.2/8.14.2/Submit) with ESMTP id n0R9oijQ016648 for ; Tue, 27 Jan 2009 09:50:44 GMT Message-Id: <200901270950.n0R9oijQ016648@news01.csr.com> X-Authentication-Warning: news01.csr.com: pws owned process doing -bs To: zsh-workers@sunsite.dk Subject: Re: sourcing a sh file in zsh In-reply-to: <20090126231630.GB18017@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> <20090126122104.0e3013ba@news01> <20090126231630.GB18017@redoubt.spodhuis.org> Comments: In-reply-to Phil Pennock message dated "Mon, 26 Jan 2009 15:16:31 -0800." Date: Tue, 27 Jan 2009 09:50:43 +0000 From: Peter Stephenson X-OriginalArrivalTime: 27 Jan 2009 09:50:44.0756 (UTC) FILETIME=[B91D4D40:01C98064] X-Scanned-By: MailControl A_08_51_00 (www.mailcontrol.com) on 10.71.0.130 X-Virus-Scanned: ClamAV 0.92.1/8908/Tue Jan 27 09:23:41 2009 on bifrost X-Virus-Status: Clean Phil Pennock wrote: > > 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. > > Given the possible behaviours I presented in zsh-workers/26336, this > seems problematic. Either the new option value set is read-only, so > that fails, or the setopt in the zsh callback function change the values > back inside the sh area. > > I think that the best thing to do would be to restore the option values > from before crossing that emulate boundary, unless the zsh function > itself has an emulate boundary. This is the road I really don't want to go down. The system is to provide a delimited execution environment where you can run code in an emulation. It is not to track every change of option at every stage in the process. Having the behaviour change bodily at explicit "emulate"s and at functions marked for emulation should be good enough, and is much more obvious behaviour than trying to insert magic conversion points. If you call to a function that doesn't fit in that environment you should make your own arrangements. I don't see why options should ever be read-only, and I don't see why executing a function that changes option values in the parent should be forbidden from doing so, given that this is explicitly supported zsh behaviour. You always have enough rope to hang yourself with a shell---if you don't want native zsh behaviour seeping out, don't use a native zsh function, or be explicit with the "emulate -L"s. -- Peter Stephenson Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070