A use-case I've long wanted it for is better "--help" messages. If you want to tell the user how to invoke the program again, argv[0] is the right thing:
Put it somewhere in $PATH, and run it as `demo --help`, and it will give:
Usage: demo [OPTIONS]
Perfect!
But with a Bash script, argv[0] is erased, it sets $0 is set to script path passed to `bash` as an argument.
Given:
#!/bin/bash
echo "Usage: $0 [OPTIONS]"
Running it as `./dir/demo --help` gives:
Usage: ./dir/demo [OPTIONS]
So good, so far, since the kernel ran "/bin/bash ./dir/demo --help". But once we get $PATH involved, $0 stops being useful, since the path passed to Bash is the resolved file path; if you put it in /usr/bin, and run it as `demo --help`, it will give:
Usage: /usr/bin/demo [OPTIONS]
Because the call to execvpe() looks at $PATH, resolves "demo" to "/usr/bin/demo", then passes "/usr/bin/demo" to the execve() syscall, and the kernel runs "/bin/bash /usr/bin/demo --help".
In POSIX shell, $0 is a little useful for looking up the source file, but isn't so useful for knowing how the user invoked you. In Bash, if you need the source file, you're better served by ${BASH_SOURCE[0]}, rendering $0 relatively useless. And neither has a way to know how the user invoked you... until now.
It's a small problem, but one that there was no solution for.
> If you want to tell the user how to invoke the program again, argv[0] is the right thing
Some pedantry: it's actually not. The argv array is a completely arbitrary thing, passed by the caller as an array of strings and packed by the kernel into some memory at the top of the stack on entry to main(). It doesn't need to correspond to anything in particular, the use of argv[0] as the file name of the program is a side effect of the way the Bourne shell syntax works. The actual file name to be executed is a separate argument to execve().
In fact there's no portable way to know for sure exactly what file was mapped into memory by the runtime linker to start your process. And getting really into the weeds there may not even be one! It would be totally possible to write a linker that loaded and relocated an ELF file into a bunch of anonymous mappings, unmapped itself, and then jumped to the entry point leaving the poor process no way at all to know where it had come from.
Sure, argv[0] is a just string, that the caller can set when they call execve(). That doesn't have mean that it doesn't have meaning. You are correct, there is no way to know how your executable was passed as the first argument to execve(). But, argv[0] is specified to mean roughly "welcome to the world, you are argv[0]", and to tell the program what it is. Sure, you could lie to the program, and tell it that it's something it's not by passing a different string to execve(), you can even do this from a Bash script with `exec -a`.
I stand by my original statement: If you want to tell the user how to invoke the program again, argv[0] is the right thing. I didn't say that running argv[0] will necessarily actually invoke the program again, I said that it's the right thing to tell the user. If the caller set argv[0] to something else, it's because they wanted your program to believe that is its identity, so that's what it should represent its identity as to the user.
Do note that was my complaint with $0, that when using $PATH it was set to that full gross path.
If /bin/foo is actually /nix/store/3508wrguwrgu3h5y9354rhfgw056y-foo-5.0/bin/foo, then when you run "foo", 0="/nix/store/3508wrguwrgu3h5y9354rhfgw056y-foo-5.0/bin/foo" and BASH_ARGV0="foo".
argv[0] is defined to be the "program name" by ISO C. What exactly this means is obviously platform dependent, and of course the caller can ignore it altogether and put something random there, but at that point they're the ones misusing the API in a way that breaks the spec.
Note that this is ISO C, not even POSIX. So ELF, Bourne shell etc are implementation details that are out of scope on this level.
I'd love to see --help start with a few examples of the most common use cases and the parameters you would use. Include the exhaustive list of parameters after that. That would make the command line much more accessible for a significant portion of users. Or at least me. I'm always forgetting the syntax of commands I use infrequently.
Yep! Not a nitpick at all. There's more than one way to do lots of things.
I prefer my version because it's easier for me to remember and read. I do use pattern substitution for other things, but I usually have to go to an interactive shell and create a test variable in order to remind myself whether I want # or %. I understand favoring built-in features over subshell calls for heavily used code, but I don't think this is especially critical for outputting usage info.
Given:
Running it as `./dir/demo --help` gives: Put it somewhere in $PATH, and run it as `demo --help`, and it will give: Perfect!But with a Bash script, argv[0] is erased, it sets $0 is set to script path passed to `bash` as an argument.
Given:
Running it as `./dir/demo --help` gives: So good, so far, since the kernel ran "/bin/bash ./dir/demo --help". But once we get $PATH involved, $0 stops being useful, since the path passed to Bash is the resolved file path; if you put it in /usr/bin, and run it as `demo --help`, it will give: Because the call to execvpe() looks at $PATH, resolves "demo" to "/usr/bin/demo", then passes "/usr/bin/demo" to the execve() syscall, and the kernel runs "/bin/bash /usr/bin/demo --help".In POSIX shell, $0 is a little useful for looking up the source file, but isn't so useful for knowing how the user invoked you. In Bash, if you need the source file, you're better served by ${BASH_SOURCE[0]}, rendering $0 relatively useless. And neither has a way to know how the user invoked you... until now.
It's a small problem, but one that there was no solution for.