Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why bother with argv[0]?

wietzebeukema.nl

Post reply on HN
Print view View original

271–277 of 277 posts

Re: Why bother with argv[0]?

#271

Post by account42 »

timrobinson333 wrote: post #56
pjc50 wrote: post #13

Earlier quoted context omitted.

There are a number of good things about CreateProcess, but argument passing is not one of them. It's a very longstanding misfeature in the design of CMD.EXE and almost certainly dates from MSDOS and therefore CP/M. A side effect of that is that programs do their own unescaping . Unix users who are used to quotes being stripped for them may be surprised by this.

Many windows programmers fail to appreciate this. If you're using a language that provides argv-style functionality, the quoting and escaping mechanism is entirely at the mercy of that language, so you can't reliably make any general assumptions about how to quote parameters to a command line

And specifically, Microsoft themselves can't even agree on the rules so Win32 API CommandLineToArgv and and the MSVCRT have slightly different quoting/escaping rules.

Re: Why bother with argv[0]?

#272

Post by Brian_K_White »

account42 wrote: post #267
iainmerrick wrote: post #203

Earlier quoted context omitted.

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 n…

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.

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.

Re: Why bother with argv[0]?

#273

Post by account42 »

Brian_K_White wrote: post #272
account42 wrote: post #267

Earlier quoted context omitted.

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.

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.

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.

Re: Why bother with argv[0]?

#275

Post by yellowapple »

piaste wrote: post #238
blenderob wrote: post #77

Earlier quoted context omitted.

> is `busybox whoami` instead of `whoami` so much more effort? It's not the "more effort" that is the deal breaker here. It is a matter of compliance with specs and user expectations. What you're suggesting would make Busybox very non-POSIXy, very non-Unixy. All scripts written over the last many decades would need to be updated to call `busybox ls` instead of `ls`? How is that a viable solution? > I'm glad the post…

Given that 'alias' is in POSIX, would a combination of (a) the hypothetical non-argv0 busybox being discussed, and (b) a POSIX shell of the maintainer's choice, with built-in aliases for 'ls=busybox ls' be sufficient to make the system POSIX complaint?

In addition to the already-raised issue of subprocesses not inheriting aliases, I'd also be worried about aliases inherently being specific to particular shells. I'd hate to have to redefine those aliases for sh, csh, zsh, fish, and Lord knows what else. It'd also be an issue for invoking those tools without going through a shell in the first place - as is common for programs launching external programs as subprocesses.

That's indeed why I personally don't use shell aliases at all, instead opting for actual shell scripts in my $PATH. Those will work no matter what shell I'm using (if any).

Re: Why bother with argv[0]?

#276

Post by Brian_K_White »

account42 wrote: post #273
Brian_K_White wrote: post #272

Earlier quoted context omitted.

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.

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.

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.

Re: Why bother with argv[0]?

#277

Post by yencabulator »

jrockway wrote: post #127

I think argv[0] is fine. It sounds like there is a lot of bad security scanning software that doesn't understand how the `exec` syscall works. That sounds like their problem and not a fundamental problem with argv[0]. Most people use argv[0] so they can do something like: $ mycommand help Type `mycommand foo bar` to foo bars. $ mycommand1.2.3 help Type `mycommand1.2.3 foo bar` to foo bars. This is admittedly less fun…

I routinely use basename(arg0) in my programs.
Post reply on HN