Zsh Mailing List Archive
Messages sorted by:
Re: 'emulate sh -c' and $0
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 `<S>' 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. `<Z>' 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:
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 <Z> 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):
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
ARGV0=sh exec zsh "$0" "$ <at> "
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
Search Src/*.c for references to "argzero", with particular attention to
Messages sorted by: