Re: 'emulate sh -c' and $0

[Richard Hansen <rhansen@xxxxxxx>]

(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