From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16882 invoked by alias); 3 Jun 2014 23:35:56 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 32688 Received: (qmail 1104 invoked from network); 3 Jun 2014 23:35:54 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED autolearn=ham version=3.3.2 X-Submitted: to socket.bbn.com (Postfix) with ESMTPSA id 9AD3840190 Message-ID: <538E5BD7.3070005@bbn.com> Date: Tue, 03 Jun 2014 19:35:51 -0400 From: Richard Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Bart Schaefer CC: zsh-workers@zsh.org Subject: Re: 'emulate sh -c' and $0 References: <5387BD0D.8090202@bbn.com> <140529204533.ZM5362@torch.brasslantern.com> <5388461D.8060203@bbn.com> <140530100050.ZM18382@torch.brasslantern.com> <5388F4C3.6070801@bbn.com> <140530221301.ZM31798@torch.brasslantern.com> <538E2CDD.7070106@bbn.com> <20140603212644.455c9981@pws-pc.ntlworld.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2014-06-03 17:10, Bart Schaefer wrote: > On Jun 3, 2014 1:27 PM, "Peter Stephenson" > wrote: >> On Tue, 03 Jun 2014 16:15:25 -0400 >> Richard Hansen wrote: >>> Although it would be a behavior change, I think it would be best if both >>> 'emulate sh' and 'emulate sh -c' set POSIX_ARGZERO by default >> >> Yes, that's the policy --- backward compatibility is for native mode, sh >> compatibility can be improved without worrying about that. > > The complexity here is that we're not just dealing with a particular > emulation, we're dealing with switching from one emulation to another (and > possibly back again) in the middle of a running shell session, and the > effect that has on a dynamically scoped variable that crosses the emulation > boundaries. Isn't this a general problem with how zsh supports mix-and-match shell code? Here's a contrived example: echo_stuff() { printf %s\\n "$*"; } foo() { ${CMD} words here; } CMD=echo_stuff IFS=_ printf "outside sh emulation: "; foo printf "inside sh emulation: "; emulate sh -c foo As stated in detail #2 in the documentation for the emulate builtin, options aren't restored when calling foo from sh emulation mode. That causes the above script to produce the following output: outside sh emulation: words_here inside sh emulation: stuff words here Because foo was defined outside of emulate I would have expected zsh to treat the body of foo as native zsh code regardless of the emulation mode of the calling code. If I hadn't read the detailed emulate rules and didn't understand how emulate worked with regard to options, I would have expected the following output: outside sh emulation: words_here inside sh emulation: words_here (same output for the same function in the same script) To get the behavior I expect, I have to do the following: define_functions() { echo_stuff() { printf %s\\n "$*"; } foo() { ${CMD} words here; } } emulate zsh -c define_functions CMD=echo_stuff IFS=_ printf "outside sh emulation: "; foo printf "inside sh emulation: "; emulate sh -c foo If zsh restored options when a non-sticky function is called from within emulation then I wouldn't have to do the above define_functions hack. (And $0 would act like I expect assuming POSIX_ARGZERO is enabled in sh emulation mode.) -Richard