5 ms·
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 i
by LukeShu 8y ago
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.
- tjoff 8y agoSurely the user already knows how to invoke the program, since he/she did it literally two seconds ago. What if I invoke it from a distant path, do I want my 73 character long path to be prepended in the --help ?
- majewsky 8y agoEspecially on something like NixOS, where /bin/bash is actually /nix/store/3508wrguwrgu3h5y9354rhfgw056y-bash-5.0/bin/bash.
- tjoff 8y agoIf you run --help you already have the path to the executable. Press the up arrow and you got it, even on nix.
- LukeShu 8y agoDo 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".