Setting environmental variable ARGV0 cause some packed software malfunctioning

[ngkz]

The runtime sets $ARGV0 which is used by zsh as argv[0] of external commands.
Because of this, when packed software calls external software which changes behavior by argv[0] via zsh, it malfunctions.

Example:

$ zsh --version
zsh 5.0.2 (x86_64-pc-linux-gnu)

$ ./Neovim-v0.3.1-1-g489d32f.glibc2.17-x86_64.AppImage --appimage-version
Version: 8c8516f

$ SHELL=/bin/zsh ./nvim -u NONE
:!sh -c "echo \$0"
sh
:!rustc --version
rustc 1.28.0 (9634041f0 2018-07-30)

$ SHELL=/bin/zsh ./Neovim-v0.3.1-1-g489d32f.glibc2.17-x86_64.AppImage -u NONE
:!sh -c 'echo $0'
./Neovim-v0.3.1-1-g489d32f.glibc2.17-x86_64.AppImage
:!rustc --version
error: command failed: 'Neovim-v0.3.1-1-g489d32f.glibc2.17-x86_64.AppImage'
info: caused by: No such file or directory (os error 2)

[probonopd]

This was the relevant discussion leading to the implementation of this feature:
#419.

It seems like we have a name clash of the variable here. Possibly we should change to another name for the variable.

Before we change it, we should find out who is using it, and send them a depreciation notice.

[TheAssassin]

I don't think we should change our variable. People rely on it, and we documented it. Isn't it part of the specification already...?

I think it's easier for neovim to change their variable name.

[probonopd]

Is it Neovim or zsh which would have to change? The former may be not so easy...

[TheAssassin]

@probonopd I just thought, neovim or whatever payload application has problems with $ARGV0 could simply set up an AppRun script that unsets $ARGV0.

[probonopd]

True. But if I am not mistaken, all AppImages launched by zsh have this issue, effectively making all AppImages unusable on zsh. Correct @ngkz?

[ngkz]

@probonopd No, this issue only occurs if the payload calls zsh, not when zsh calls the payload.
This is because the runtime sets $ARGV0, and it propagates from the runtime to zsh via the payload, and then zsh uses it as argv[0] of the external command.

[TheAssassin]

So, unsetting it in AppRun would work fine...

[probonopd]

Thanks for the clarification @ngkz - in this case a custom AppRun that unsets $ARGV0 will do the trick indeed. Let us know if you need assistance on how to do this.

[azubieta]

Hi @ngkz, did the comments above help you solving the issue?

[TheAssassin]

We agreed on AppRun to be the place to solve this. Please reopen if you disagree.

[justinmk]

@probonopd @TheAssassin We've updated the Neovim appimage to work around this issue. For future reference, what other environment variables is AppImage setting ?

Searching the docs for ARGV0 yields nothing: https://docs.appimage.org/search.html?q=argv0&check_keywords=yes&area=default

Also do not see an "environment" page on the wiki.

[probonopd]

Please see https://discourse.appimage.org/t/call-alternative-binary-from-appimage/93/10.
cc @TheAssassin, do we want this to become a documented feature?

[TheAssassin]

Sure! PRs welcome for https://github.com/AppImage/docs.appimage.org. The environment variables should have been documented already, actually, but it seems they're missing.

[erw7]

I added an explanation about ARGV0 to the wiki. Please correct it if there is a more appropriate place or explanation.

[TheAssassin]

@erw7 as mentioned (#852 (comment)), https://github.com/AppImage/docs.appimage.org.

[nelsonenzo]

Thanks for the clarification @ngkz - in this case a custom AppRun that unsets $ARGV0 will do the trick indeed. Let us know if you need assistance on how to do this.

@probonopd could you give me some guidance on how to do this? I'm having this same issue with my tmux-appimage. I appreciate your help.

[probonopd]

Inside your AppDir, delete the AppRun symlink and replace it with a script of the same name:

#!/bin/bash
HERE="$(dirname "$(readlink -f "${0}")")"
unset ARGV0
exec "${HERE}/usr/bin/tmux" "$@"

I have tested it and it works.