From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10800 invoked from network); 24 Jan 2009 20:47:47 -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=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; 24 Jan 2009 20:47:47 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 59078 invoked from network); 24 Jan 2009 20:47:41 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 24 Jan 2009 20:47:41 -0000 Received: (qmail 11054 invoked by alias); 24 Jan 2009 20:47:36 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26416 Received: (qmail 11036 invoked from network); 24 Jan 2009 20:47:35 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 24 Jan 2009 20:47:35 -0000 Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by bifrost.dotsrc.org (Postfix) with ESMTP id 723DE802720F for ; Sat, 24 Jan 2009 21:47:20 +0100 (CET) Received: by fg-out-1718.google.com with SMTP id e21so2832691fga.37 for ; Sat, 24 Jan 2009 12:47:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kOa+oklwLyc19GTw6Cz+jcYqgNqWmuvfDeMQQyO3+ks=; b=Wie0YU5DSSuu9zfiiMPSN8qxhDzC0Ken30KYsRJGbUcaer+nFtekvqnqHUi1uFpKRa +tna/dnuB2rPRX7ra9sKzAjScvgrwKG5ki6xC9SK/hQ4eIllmTyp5UnTmZ0wa3gNqqg9 pC93gwDOCFkDlrTXNZ3UiQ9OGAIJQI59HJpPE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=n2R2BUha6KMk3zwoK0579JHBnD22YRV1yE2TAwi0UnT1f5bh/BF6ax9O14oyPJ2fU4 ku5VuSXd7xYOmiy54IC3SkC6e8kqZ9gWbkgbLUHKFQ1NSJoRZst8Z5Wqhln9hwMRSqxD BdqfTQgMtTi7jljNRVLE9rsvggNyK0xO2mOIE= MIME-Version: 1.0 Received: by 10.86.89.20 with SMTP id m20mr3909369fgb.71.1232830039838; Sat, 24 Jan 2009 12:47:19 -0800 (PST) In-Reply-To: <20090124173836.64403fdc@pws-pc> References: <200901161939.54651.arvidjaar@newmail.ru> <090116102934.ZM22119@torch.brasslantern.com> <200901241859.30029.arvidjaar@gmail.com> <20090124173836.64403fdc@pws-pc> Date: Sat, 24 Jan 2009 21:47:19 +0100 Message-ID: <2d460de70901241247v5358bcddja7b744fa9a66f016@mail.gmail.com> Subject: Re: sourcing a sh file in zsh From: Richard Hartmann To: Peter Stephenson Cc: zsh-workers@sunsite.dk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92.1/8899/Sat Jan 24 14:06:33 2009 on bifrost X-Virus-Status: Clean On Sat, Jan 24, 2009 at 18:38, Peter Stephenson wrote: > I don't think functions should > *always* inherit the emulation because it changes the current behaviour > too much---we would be resetting a whole load of options before every > function call. Me neither. If people think this is useful, it might make sense as an option, but it's way too magical for my taste. > I would guess we don't want to apply it to autoloaded functions which > already have their own rules. We can also add commands to tweak the > emulation mode for individual functions, but that can be done > separately. > > We do need to be quite clear on the rules to avoid tying ourselves in > knots with things like "emaulate -LRE sh autoload foo". "foo", in my > interpretation, would not inherit sh behaviour here. I think nested > "emulate"s should be unproblematic, however. Agreed. Richard