From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6336 invoked from network); 31 Jan 2009 20:41:34 -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; 31 Jan 2009 20:41:34 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 45906 invoked from network); 31 Jan 2009 20:41:30 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 31 Jan 2009 20:41:30 -0000 Received: (qmail 28086 invoked by alias); 31 Jan 2009 20:41:25 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26500 Received: (qmail 28070 invoked from network); 31 Jan 2009 20:41:24 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 31 Jan 2009 20:41:24 -0000 Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by bifrost.dotsrc.org (Postfix) with ESMTP id 9B35B802720F for ; Sat, 31 Jan 2009 21:41:09 +0100 (CET) Received: from torch.brasslantern.com ([96.238.220.215]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-2.01 (built Jun 13 2007; 32bit)) with ESMTPA id <0KEC000VWS3WO165@vms173005.mailsrvcs.net> for zsh-workers@sunsite.dk; Sat, 31 Jan 2009 14:40:49 -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 n0VKehSU007793 for ; Sat, 31 Jan 2009 12:40:43 -0800 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id n0VKeh6Y007792 for zsh-workers@sunsite.dk; Sat, 31 Jan 2009 12:40:43 -0800 From: Bart Schaefer Message-id: <090131124043.ZM7791@torch.brasslantern.com> Date: Sat, 31 Jan 2009 12:40:43 -0800 In-reply-to: <200901311132.28144.arvidjaar@gmail.com> Comments: In reply to Andrey Borzenkov "Re: sourcing a sh file in zsh" (Jan 31, 11:32am) References: <200901261949.54010.arvidjaar@gmail.com> <090129202501.ZM21284@torch.brasslantern.com> <200901311132.28144.arvidjaar@gmail.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@sunsite.dk Subject: Re: sourcing a sh file in zsh MIME-version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.92.1/8931/Sat Jan 31 19:25:59 2009 on bifrost X-Virus-Status: Clean On Jan 31, 11:32am, Andrey Borzenkov wrote: } } > I *didn't* expect an equivalence to function scopes with respect to } > any setopts that aren't normally affected by changing the emulation. } } This is doable. I did not quite like it because my primary intention } was to run foreign code. In which case I definitely would not like } this code by accident change shell behaviour. So it is sort of } sandbox. This is a tricky problem. What, for example, should happen when one does emulate sh -c 'set -x' ?? I'd initally have expected XTRACE to become and remain set. However, I can see reasons for doing it either way, so as long as whatever is chosen is documented I'm OK with it. We face a similar problem with the "sticky" emulation idea. Let's suppose for purposes of illustration that "emulate -S" activates it. emulate -S sh -c 'debug() { set -vx }' (Imagine the debug function is buried in, and used by, some lengthy piece of /bin/sh code that's being loaded.) What happens when the debug function is executed? An implicit LOCAL_OPTIONS breaks the intended behavior. } I think we need to sort this out before usage sticks. Absolutely. } So let's consider what we get } } emulate -L -c "command" } implicitly set LOCAL_OPTIONS before executing command Well, no. Literally setting LOCAL_OPTIONS has side-effects within other functions that might be defined by the command. Everything here has to be described in terms of "behaves as if". I suppose we could do it this way (rope to hang yourself and all that, no different than putting an "emulate -L" in your .zshrc) but I'm not opposed to -L / -c as mutually exclusive. } emulate [-R] -c "command" } implicitly do "emulate [-R] oldemulation" after executing command } } Do I miss something? Is it what you intend? That's pretty much what my original thought was, yes, but again I can see the argument both ways.