From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16771 invoked by alias); 30 May 2014 09:22:46 -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: 32628 Received: (qmail 10197 invoked from network); 30 May 2014 09:22:32 -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 3A44540B71 Message-ID: <5388461D.8060203@bbn.com> Date: Fri, 30 May 2014 04:49:33 -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> In-Reply-To: <140529204533.ZM5362@torch.brasslantern.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit (please cc me in replies as I am not subscribed to the list) On 2014-05-29 23:45, Bart Schaefer wrote: > On May 29, 7:04pm, Richard Hansen wrote: >> >> I just encountered what I think is a bug in Zsh 5.0.5. > > To the extent that it's working exactly as documented, it's not a bug ... Would you mind pointing me to where this specific behavior is documented? It was non-obvious to me when I was digging around. (I am aware of the documentation for the FUNCTION_ARGZERO option. I'm more interested in what it really means to be running in sh emulation mode, as that's where I think the bug is.) >> zsh -c ' >> emulate sh -c "echo \"\$0\"" >> bar() { emulate sh -c "echo \"\$0\""; } >> bar >> ' foo arg1 >> >> I expected it to produce: >> >> foo >> foo > > If you throw in "unsetopt functionargzero" any time before calling "bar" > then it does produce that output. > > If you rewrite your example as > > zsh -c ' > emulate sh -c "echo \"\$0\"" > emulate sh -c "bar() { echo \"\$0\"; }" > bar > ' foo arg1 > > then it also produces your expected output; you just need to define the > function in the right scope. It is not always possible to unset that option in a meaningful way -- the code that sources the file with POSIX shell code may itself be in a file that has been sourced. By that time, $0 has already been overridden. Moving the unsetopt up another level may not be desirable/feasible. For example: cat <<\EOF >foo.zsh # zsh-specific code goes here unsetopt FUNCTION_ARGZERO . ./bar.sh # zsh-specific code goes here EOF cat <<\EOF >bar.sh printf %s\\n "$0" EOF zsh -c '. ./foo.zsh' baz >> This is relevant when sourcing a file containing (POSIX) sh code that >> might examine $0 (e.g., for logging or to 'exec "$0" "$@"' after >> exporting/unsetting environment variables). >> >> Perhaps Zsh should save the original value of $0 somewhere and restore >> it when entering sh emulation mode. > > I don't find those examples particularly compelling, Here's the real-world problem that motivated my bug report; perhaps it is a more compelling example (or perhaps you'll think of a better way to solve the problem I was addressing): http://article.gmane.org/gmane.comp.version-control.git/250409 > but the original > value of $0 is already stashed; what would need to change is that the > *local* value of $0 gets temporarily replaced by the global one. That's good news; that should make it easier to write a patch that temporarily replaces the local value with the global value. Would you (or anyone else in the community) be opposed to such a patch? If not, can you point me to the relevant bits of code to help me get started? Thanks, Richard