[Brian_K_White]

This is stupid. argv0 is just some data like any other data.

It's ridiculously useful aside from the obvious busybox style usage.

It's huge to be able to have a pointer to the directory where the executable resides, so you can package other assets along side it and have it all work for free without a seperate configuration file or env variables etc.

Or for debugging or even non-error logging. You might call a binary from more than one place by other means than symlinks or hard links. You might be running from different mounted filsystems, chroot or container environments etc. A symlink might be in the middle of the path and not the executable name itself. Similarly a mount point.

It's just a random small useful tool like all others. Calling it some kind of security problem is like saying that screwdrivers are a security problem because aside from turning screws, some people can use screwdrivers to stab people, and we have nut drivers which can almost serve almost all the same needs for only a little extra work.

If your context of the moment means you have a security concern where you shouldn't trust this bit of data as gospel for some reason, then don't. Treat it like user input and take whatever precautions and fallback measures and sanity checks make sense for you in whatever particular situation you are in.

F-ing dumb.

[iainmerrick]

It's huge to be able to have a pointer to the directory where the executable resides, so you can package other assets along side it and have it all work for free without a seperate configuration file or env variables etc.

Yes! I was surprised how far down I had to scroll to find somebody mentioning that one.

How else can you write a reasonably robust script that actually, you know, does something? You almost always need to grab some known files by their paths relative to the script.

[account42]

argv[0] isn't actually a great solution for that since it isn't required to contain any path and in practice won't depending how the program was called.

Some languages don't provide a better solution but they should. For Bash there is ${BASH_SOURCE[0]}. For compiled executables you use OS-provided functions like GetModuleFileName(NULL, ...) on Windows and readlink("/proc/self/exe", ...) on Linux.

[Brian_K_White]

It's neither great nor not-great, it's just some info that is what it is and isn't what it isn't. It's useful when it's useful, and not what it's not.

[account42]

The point is that using argv[0] to get the executable location can be quite fragile in practice and there are (OS-specific) alternatives that work much better for that goal.

[Brian_K_White]

It's not fragile at all. It's also cross platform without 18 ifdefs. It also doesn't necessarily or only tell you where the exe is, it tells you what was called. And maybe you want to know that. If sometimes you don't, so what? No one can say for anyone else that they do or don't need this bit of info, or should or shouldn't make assumptions based on it. The fitness for purpose is 100% context dependant. You have to be looking at some particular app and the rest of the environment it's running within before you can say "argv should not be consulted here, we should use this other interface instead" You can't say anything like that as a general case that automatically applies to everything.