From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28859 invoked from network); 26 Jan 2009 23:16:48 -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; 26 Jan 2009 23:16:48 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 33718 invoked from network); 26 Jan 2009 23:16:44 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 26 Jan 2009 23:16:44 -0000 Received: (qmail 9931 invoked by alias); 26 Jan 2009 23:16:38 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26455 Received: (qmail 9913 invoked from network); 26 Jan 2009 23:16:37 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 26 Jan 2009 23:16:37 -0000 Received: from mx.spodhuis.org (redoubt.spodhuis.org [193.202.115.177]) by bifrost.dotsrc.org (Postfix) with ESMTPS id 1C27D80271F0 for ; Tue, 27 Jan 2009 00:16:31 +0100 (CET) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=d200807; d=spodhuis.org; h=Received:Date:From:To:Subject:Message-ID:Mail-Followup-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=zHNCuCtW5RcI9N87htclZn8S+KF3qWFrYXe/bi1AXUX76VDuKWksW/qXJUvVFoqUVWMi6Q2RqX9R2SLFAC7xtc4oGsXko50OkgAtDX8FezlgXaNLgd663xmEdTjQ/sX/9Xhx6+Nz0hCsJr5scpWDeXQ05vOd6WQ8GL1DpnjF3mw=; Received: by smtp.spodhuis.org with local id 1LRagx-000LOg-28; Mon, 26 Jan 2009 23:16:31 +0000 Date: Mon, 26 Jan 2009 15:16:31 -0800 From: Phil Pennock To: zsh-workers@sunsite.dk Subject: Re: sourcing a sh file in zsh Message-ID: <20090126231630.GB18017@redoubt.spodhuis.org> Mail-Followup-To: zsh-workers@sunsite.dk 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090126122104.0e3013ba@news01> X-Virus-Scanned: ClamAV 0.92.1/8905/Mon Jan 26 18:29:36 2009 on bifrost X-Virus-Status: Clean On 2009-01-26 at 12:21 +0000, Peter Stephenson wrote: > 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. You have made me very happy. Thank you. (the compressed Eprog stuff has always scared me away) > 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. I think that I shall have to write tests covering these cases and post them before I write code to implement it -- anything else is too fraught with peril. -Phil