From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 553 invoked by alias); 30 May 2014 17:01:07 -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: 32629 Received: (qmail 19344 invoked from network); 30 May 2014 17:01:02 -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=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 From: Bart Schaefer Message-id: <140530100050.ZM18382@torch.brasslantern.com> Date: Fri, 30 May 2014 10:00:50 -0700 In-reply-to: <5388461D.8060203@bbn.com> Comments: In reply to Richard Hansen "Re: 'emulate sh -c' and $0" (May 30, 4:49am) References: <5387BD0D.8090202@bbn.com> <140529204533.ZM5362@torch.brasslantern.com> <5388461D.8060203@bbn.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Richard Hansen Subject: Re: 'emulate sh -c' and $0 Cc: zsh-workers@zsh.org MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On May 30, 4:49am, Richard Hansen wrote: } } 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 don't pretend there couldn't be more clarity in the zsh documentation, but under "Parameters" there's first this: In the parameter lists that follow, the mark `' indicates that the parameter is special. Special parameters cannot have their type changed or their readonly attribute turned off, and if a special parameter is unset, then later recreated, the special properties will be retained. `' indicates that the parameter does not exist when the shell initializes in sh or ksh emulation mode. And then in the "Parameters Set by the Shell" subsection there is: 0 The name used to invoke the current shell. If the FUNCTION_ARGZERO option is set, this is set temporarily within a shell function to the name of the function, and within a sourced script to the name of the script. There's no there, and there's no mention in the "Compatibility" section about the behavior of $0, only that NO_FUNCTION_ARGZERO is set. Finally the entry for the emulate builtin says: With single argument set up zsh options to emulate the specified shell as much as possible. `csh' will never be fully emulated. If the argument is not one of the shells listed above, zsh will be used as a default; more precisely, the tests performed on the argument are the same as those used to determine the emulation at startup based on the shell name, see Compatibility. } (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.) In general, emulation is at its most complete if and only if the shell is actually started as an emulator (e.g., the path name to the shell binary itself is not zsh, or ARGV0 is set in the environment). The "emulate" builtin only changes setopts to the closest possible. } > 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 Instead of "compelling" I perhaps should have said "likely to come up in common usage." You have a fairly rare special case there. In that example, ARGV0=sh exec zsh "$0" "$ " might do what you want, but I'm not entirely following from the diff context what's intended. } > 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. Unfortunately the way the local value is implemented is usually to use C local variable scoping to stash and restore the contents of a C global pointer, so this would mean at least one additional C global. } Would you (or anyone else in the community) be opposed to such a patch? The use cases in both directions seem pretty unusual to me. Losing the ability to "localize" $0 for scripts feels almost as likely to create questions as does your situation. I suppose if both values were in the C global state, it would be possible to have the "correct" one appear at the instant functionargzero changes, instead of being determined by the setting at the time the function is entered. OTOH that would be a larger behavior difference / lack of backward compatibilty. } If not, can you point me to the relevant bits of code to help me get } started? Search Src/*.c for references to "argzero", with particular attention to builtin.c:bin_emulate.