From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4703 invoked from network); 1 Feb 2009 18:03:42 -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.6 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; 1 Feb 2009 18:03:42 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 2861 invoked from network); 1 Feb 2009 18:03:36 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 1 Feb 2009 18:03:36 -0000 Received: (qmail 27595 invoked by alias); 1 Feb 2009 18:03:31 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26505 Received: (qmail 27583 invoked from network); 1 Feb 2009 18:03:31 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 1 Feb 2009 18:03:31 -0000 Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by bifrost.dotsrc.org (Postfix) with ESMTP id 72FF680271F0 for ; Sun, 1 Feb 2009 19:03:28 +0100 (CET) Received: by fg-out-1718.google.com with SMTP id l26so387005fgb.37 for ; Sun, 01 Feb 2009 10:03:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=a+WsGI8a2hBnxX5isKYl91oyst3Z5dUUj4F2GxIICgo=; b=iRFmxfTlcJkCXFb6asWB30X62OPkb0OLGK2zYaV+w6F3m8UyKwuUls2kUuUuwXqdPe g6kb1164VXOrL45C6XJGvm9dvHTAzQnR3njIggxUTjPRlaWsgV9BGVEKxiHIOGfdqO1c OLsCY0holj7YIvDzol68K2YzNiZwkSJC8cRiE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; b=JLj9FiVhugFcVaXQdcy/HIt4wVUQNS9sHo9CGpSavulpwlAHvfkGpzbG0cqANFovVt efGHMIMiwm7B/Ji3Rno0g79Y5b3nPP8IUwhLjBOIwV58SN+DvX8IE0yK+Eiylqsct8yZ IbNNiA1ZYqJ8KEhM8B1QCIkoG4gDmuWbHxxWA= Received: by 10.86.80.17 with SMTP id d17mr1062550fgb.55.1233511406851; Sun, 01 Feb 2009 10:03:26 -0800 (PST) Received: from cooker.localnet (ppp91-77-249-206.pppoe.mtu-net.ru [91.77.249.206]) by mx.google.com with ESMTPS id e20sm3997450fga.46.2009.02.01.10.03.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 01 Feb 2009 10:03:25 -0800 (PST) From: Andrey Borzenkov To: zsh-workers@sunsite.dk Subject: Re: sourcing a sh file in zsh Date: Sun, 1 Feb 2009 21:03:15 +0300 User-Agent: KMail/1.11.0 (Linux/2.6.29-rc3-1avb; KDE/4.2.0; i686; ; ) References: <200901311132.28144.arvidjaar@gmail.com> <090131124043.ZM7791@torch.brasslantern.com> In-Reply-To: <090131124043.ZM7791@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1832746.2NqMpZxY7C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200902012103.20658.arvidjaar@gmail.com> X-Virus-Scanned: ClamAV 0.92.1/8935/Sun Feb 1 16:43:52 2009 on bifrost X-Virus-Status: Clean --nextPart1832746.2NqMpZxY7C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 31 of January 2009 23:40:43 Bart Schaefer wrote: > } 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. > Yes, mea culpa. I did mean "as if LOCAL_OPTIONS were set". IOW restore=20 options to the values they had before emulate command. > } 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. Unfortunately this one probably would be the most confusing=20 implementation. This effectively results in options values after emulate=20 that corresponds neither to options values before, nor to options set by=20 commands inside of emulate -c. If user has changed any of the option that is touched by emulate (and=20 emulate -R would touch every option) before executing emulate -c, return=20 from emulate -c would wipe out all changes. We could try to interpret this as "set of options that were in effect=20 before emulate -c as adjusted by options explicitly changed by command".=20 This is doable, but this immediately poses another question - what to do=20 with emulation mode set inside emulate -c? Extreme example: emulate sh -c "emulate -R csh" if we retain options set by "emulate -R csh" on exit from top level=20 emulate, we effectively have options for csh emulation, but emulation=20 itself is reset to whatever was in effect before (just in case -=20 emulation is *not* limited to options unfortunately). So I still tend to leave things as is (making documentation more clear)=20 and if we ever need different behaviour, better add explicit option for=20 it. --nextPart1832746.2NqMpZxY7C Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkmF4+QACgkQR6LMutpd94zLtgCeK4/dXV2jg+w6k1m3YLR23Bcq +JsAoNGZmorFukZdTtsRHSY8pAnrE3v0 =OlPc -----END PGP SIGNATURE----- --nextPart1832746.2NqMpZxY7C--