From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1902 invoked from network); 31 Jan 2009 21:40:26 -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 21:40:26 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 69182 invoked from network); 31 Jan 2009 21:40:22 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 31 Jan 2009 21:40:22 -0000 Received: (qmail 26912 invoked by alias); 31 Jan 2009 21:40:17 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26502 Received: (qmail 26899 invoked from network); 31 Jan 2009 21:40:17 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 31 Jan 2009 21:40:17 -0000 Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44]) by bifrost.dotsrc.org (Postfix) with ESMTP id D173A80271F0 for ; Sat, 31 Jan 2009 22:40:13 +0100 (CET) Received: from torch.brasslantern.com ([96.238.220.215]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0KEC00BRPUUHS31C@vms044.mailsrvcs.net> for zsh-workers@sunsite.dk; Sat, 31 Jan 2009 15:39:56 -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 n0VLdrGq007973 for ; Sat, 31 Jan 2009 13:39:53 -0800 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id n0VLdqmu007972 for zsh-workers@sunsite.dk; Sat, 31 Jan 2009 13:39:52 -0800 Date: Sat, 31 Jan 2009 13:39:52 -0800 From: Bart Schaefer Subject: Re: sourcing a sh file in zsh In-reply-to: <200901312110.n0VLA2bR006281@pws-pc.ntlworld.com> To: zsh-workers@sunsite.dk Message-id: <090131133952.ZM7971@torch.brasslantern.com> MIME-version: 1.0 X-Mailer: OpenZMail Classic (0.9.2 24April2005) Content-type: text/plain; charset=us-ascii References: <200901312110.n0VLA2bR006281@pws-pc.ntlworld.com> Comments: In reply to Peter Stephenson "Re: sourcing a sh file in zsh" (Jan 31, 9:10pm) X-Virus-Scanned: ClamAV 0.92.1/8931/Sat Jan 31 19:25:59 2009 on bifrost X-Virus-Status: Clean On Jan 31, 9:10pm, Peter Stephenson wrote: } Subject: Re: sourcing a sh file in zsh } } Bart Schaefer wrote: } > 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 }' } } What would be the intention of the code above, anyway? Well, suppose I've got this sort of thing in a file somewhere: debug() { set -vx } big_hairy_sh_app() { if [[ x$1 = x-d ]]; then debug; shift; fi do_some_sh_stuff do_more_sh_stuff } do_some_sh_stuff() { echo whatever } do_more_sh_stuff() { echo whocares } The intent would be to run emulate -S sh -c 'source big_hairy_sh_app_as_a_function_library.sh' and them later invoke it with big_hairy_sh_app -d and have all the right emulation settings magically take effect. If *every* function defined in the sourced file gets an implicit LOCAL_OPTIONS by virtue of emulation stickyness, then even within the call to big_hairy_sh_app the embedded call to debug is going to clear XTRACE and VERBOSE upon returning, and the -d option to the function library has become useless. I'm with you that we may just have to say "tough cookies" but we at least need to understand what we're not allowing. } To get this right (if that is right), we do need to be careful about } how } we handle sticky emulation in functions: if we're already in the } sticky emulation environment, as here, we don't want to set and restore } options around execution of functions defined in the same emulation } mode. I agree, but that means that "already in the sticky" may have to include "have entered a function that was originally defined with the sticky." } That would be regardless of which chunks of code they were } defined in, I think, otherwise we have a new type of firewall (between } code chunks rather than emulations) that we don't want. } } In other words, your orignal code chunk would be fine if combined with } other code defined in another "emulate sh -c ..." chunk. I think that's } all we need to get the job done. Yep, devil in details.