How to receive name with which the script was invoked

[septatrix]

Fish always seem to use the absolute path when invoking scripts with a shebang. E.g.:

#!/usr/bin/fish
echo (status filename)

# or
#!/usr/bin/sh
echo $0

The above always return the resolved path even when invoked as ./test whereas it usually is mirroring what was typed on the command line. I think it is actually useful to get the resolved path as given by (status filename) however I see no way to obtain the "expected" value as would be given when invoking this from other shells (bash, zsh, etc.).

This is problematic as it is often required to get the way the command was invoked, e.g. for help texts. Is there any way to receive this information otherwise? I start to fear not however this goes against the widespread convention that argv[0] equals what was typed...

[faho]

The above always return the resolved path

The path will be absolutized, because fish passes the absolute path as argv[0], but it won't be "resolved".

E.g. create /tmp/foo.fish:

#!/usr/bin/fish
echo Hi my name is (status filename)

make it executable, run it via /tmp/foo.fish or ./foo.fish and it will print "Hi my name is /tmp/foo.fish".

But make a symlink /tmp/bar.fish, pointing to /tmp/foo.fish, and run that, and you'll get "Hi my name is /tmp/bar.fish".

Tbh I don't see the need in doing anything else for help texts or busybox-like argv[0]-based tool changing. The full path is usable, the basename is whatever file you were executed through - either of which could serve as your name.

[septatrix]

The path will be absolutized, because fish passes the absolute path as argv[0], but it won't be "resolved".

Yeah I mixed the terminology a bit at the end but meant absolute (also tried it locally beforehand).

Tbh I don't see the need in doing anything else for help texts or busybox-like argv[0]-based tool changing. The full path is usable, the basename is whatever file you were executed through - either of which could serve as your name.

It also is not wrong per se (otherwise I would have opened an issue) just unusual/unexpected and it was therefore very confusing to me why fish does this. In my case I want to show the user an auto corrected version without all the useless directories beforehand. Think like:

foobar is not available any more, try barfoo instead:
./how-the-script/was-initially-invoked.py barfoo

Such that the user can just select and paste it into the terminal again. Almost¹ no information is be lost as I can still recover the entered command by returning argv0 relative to the current working directory (pathlib.Path(argv0).relative_to(pathlib.Path.cwd())) in most cases. That being said it is kind of a bummer to go through these loops for only fish whereas the other shells rock the expected behaviour.
It is also sadly not possible (to my knowledge) to correctly recover the path when using some .. to go higher than the working directory or differentiate between ./script and /absolute/path/to/script.

Was the absolutization implemented for a specific reason? Otherwise (if it is simple to add) could I make a PR combating this information loss?

[faho]

That being said it is kind of a bummer to go through these loops for only fish whereas the other shells rock the expected behaviour.

argv[0] can contain arbitrary contents. A common special case is prefixing something with - to denote a login shell - -sh, but that's only one possibility. It can even be NULL, which can even lead to security issues - see https://ryiron.wordpress.com/2013/12/16/argv-silliness/.

You shouldn't really rely on it for anything other than printing a nice error or figuring out which busybox widget you are. For either of those, status basename works.

Otherwise (if it is simple to add) could I make a PR combating this information loss?

I don't think it's all that simple - it would have to work both with execve and the new posix_spawn hotness (we use the latter and fall back on the former when we have to).

I wouldn't be interested in reviewing it, because I don't see the use case.

[septatrix]

argv[0] can contain arbitrary contents. [...] You shouldn't really rely on it for anything other than printing a nice error or figuring out which busybox widget you are. [...]

Yes I am aware that its content is entirely unspecified though that does not mean that one must avoid it - it is still useful most of the time like in my above example.

Otherwise (if it is simple to add) could I make a PR combating this information loss?

I don't think it's all that simple - it would have to work both with execve and the new posix_spawn hotness (we use the latter and fall back on the former when we have to).

I wouldn't be interested in reviewing it, because I don't see the use case.

I currently do not really have time for it nor in the foreseeable future but there does not seem to be anything fundamentally preventing this so if I have a few hours on a weekend in the future I might take a stab at it.
If (and according to you that is a big if) it turns out to be rather simple and clean I will create a PR.

[floam]

I'll review a PR that helps preserve argv[0]-kind of information, ideally it should be pretty simple diffs though.

There is a fair bit of code in fish that does extra work to construct "full paths" because of idiosyncrasies that no longer actually exist, this kind of reminds me of stuff like that.