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

111–120 of 277 posts

Re: Why bother with argv[0]?

#111

Post by mariusor »

Hizonner wrote: post #108
mariusor wrote: post #105

Earlier quoted context omitted.

Busybox is quite well known project, but frankly from the way you write about it, it does not look like you know how it works so apologies if I'm explaining something that you already know. Busybox is a reimplementation of the standard linux utils (ls, find, dir, etc..) for resource limited machines. To quote from the man page: > BusyBox is a multi-call binary that combines many common Unix > utilities into a single…

I know exactly how it works, thanks. The hangup here seems to be the definition of "program". I'm using it to mean something roughly like "executable", which I think is fairly close to what the original article meant it to mean. You seem to be using some concept of "program" that makes each of busybox's functions a separate program. As far as I'm concerned, on the other hand, busybox is one big program that does a lo…

OK, apologies.

Then your previous statement makes no sense in context. At least to me.

Yes busybox knows it's busybox. But busybox doesn't do anything if it is not invoked in a certain way which relies on argv[0] being what it is today. I am not sure what you're arguing for frankly.

Re: Why bother with argv[0]?

#112

Post by hi-v-rocknroll »

Arguing against legacy quirks is arguing against compatibility and arguing for throwing away decades of code portability guarantees through 20/20 hindsight perfectionism failing to consider the costs and burdens of reimagining the world with bikeshedding rants.

Re: Why bother with argv[0]?

#113

Post by DSMan195276 »

skobes wrote: post #16

"Windows’ own API calls for creating new processes (such as CreateProcess [6], ShellExecute [7]) do not allow you to set argv[0]: it sets it for you, based on how the path to the executable was provided." Isn't this contradicted by the docs? CreateProcess receives lpApplicationName and lpCommandLine, and they can be different.

Yeah they have this incorrect. if you provide `lpApplicationName` and `lpCommandLine` then the application name is not automatically added to the command line string, you have to add it yourself to the string provided as `lpCommandLine`. I checked and the docs for `CreateProcess` briefly mention this issue:

> If both lpApplicationName and lpCommandLine are non-NULL, the null-terminated string pointed to by lpApplicationName specifies the module to execute, and the null-terminated string pointed to by lpCommandLine specifies the command line. The new process can use GetCommandLine to retrieve the entire command line. Console processes written in C can use the argc and argv arguments to parse the command line. _Because argv[0] is the module name, C programmers generally repeat the module name as the first token in the command line._

Re: Why bother with argv[0]?

#114

Post by hi-v-rocknroll »

avidiax wrote: post #4

It is sometimes used to allow one binary to be the symlink target of hundreds of commands. Android does this for most common shell commands. Toybox and busybox are examples of such implementations. https://github.com/landley/toybox https://en.m.wikipedia.org/wiki/BusyBox

coreutils-static did this too. The advantage of shared libraries and multiple-use single static binaries is they're only loaded once.

Re: Why bother with argv[0]?

#115

Post by sophacles »

blenderob wrote: post #88
surajrmal wrote: post #78

Earlier quoted context omitted.

You can write a 2 liner shell script that prepends busybox per command. I've done this on a 16MiB restricted system and while ate maybe 4k per command, it wasn't a big deal with only 20-30 commands.

What about compiled binaries that for one reason or another is doing an execve() on "/usr/bin/cmp" or some such thing? Do you propose changing every script and every binary on earth that expects Busybox to be a POSIXy, Unixy environment?

No you make this script:

   #!/bin/sh
   exec /bin/busybox cmp
And place it at /usr/bin/cmp

Re: Why bother with argv[0]?

#116

Post by zokier »

yjftsjthsd-h wrote: post #44

So obviously claiming that there's no good reason for process to read argv[0] is either demonstrating the author's ignorance or needs a much stronger defense; I'd be fascinated to hear how they think busybox should work on an OpenWrt box with a 16MB root filesystem. However , I am willing to consider the discussion about whether there could be merit to restricting the ability to write that value; I could imagine a sy…

Isn't the reason for busybox multi-call binary mostly just ELF being bloated? So the answer for resource constrained systems would be to have more efficient executable format. I don't see why multi-call binary + bunch of symlinks would be intrisically much more size-efficient than something purpose-built.

Re: Why bother with argv[0]?

#117

Post by Sohcahtoa82 »

Suppafly wrote: post #47
JohnFen wrote: post #7

> Today however, disk space is no longer considered an issue On desktop machines, perhaps, but this is certainly not true on all platforms Linux runs on.

Plus the whole "space is not an issue" thing along with "you can just add more ram" is the reason everything is so bloated and slow even on well provisioned machines.

These days, Windows Calculator takes up more memory than mIRC.

Tell me why a simple calculator app needs more memory than a complete multi-server implementation of the IRC protocol (including SSL/TLS), not to mention a full scripting engine.

Re: Why bother with argv[0]?

#118

Post by skobes »

magicalhippo wrote: post #61
skobes wrote: post #16

"Windows’ own API calls for creating new processes (such as CreateProcess [6], ShellExecute [7]) do not allow you to set argv[0]: it sets it for you, based on how the path to the executable was provided." Isn't this contradicted by the docs? CreateProcess receives lpApplicationName and lpCommandLine, and they can be different.

Not the way I understand it. In the execv documentation[1], you pass the program name twice: int execv(const char *path, char *const argv[]); The argument path points to a pathname that identifies the new process image file. The argument argv is an array of character pointers to null-terminated strings. [..] The value in argv[0] should point to a filename string that is associated with the process being started by on…

> Windows does not allow you to do that, AFAIK.

It does though, using the lpCommandLine parameter to CreateProcess as I said.

CreateProcess("main.exe", "foobar", ...)

argv[0] is "foobar"

Re: Why bother with argv[0]?

#119

Post by Hizonner »

mariusor wrote: post #111
Hizonner wrote: post #108

Earlier quoted context omitted.

I know exactly how it works, thanks. The hangup here seems to be the definition of "program". I'm using it to mean something roughly like "executable", which I think is fairly close to what the original article meant it to mean. You seem to be using some concept of "program" that makes each of busybox's functions a separate program. As far as I'm concerned, on the other hand, busybox is one big program that does a lo…

OK, apologies. Then your previous statement makes no sense in context. At least to me. Yes busybox knows it's busybox. But busybox doesn't do anything if it is not invoked in a certain way which relies on argv[0] being what it is today. I am not sure what you're arguing for frankly.

I'm arguing against the idea that the way argv[0] works is somehow wrong, and/or perhaps should be changed to "more reliably" reflect the filename of the executable that actually got loaded, because some programmer might not understand what argv[0] actually does.

The article's lead argument for the "badness" of argv[0] seems to be, roughly paraphrased, that "the program should already know what it is [true], and this could confuse it [Huh? No I don't really know what that means either]". That's followed by a bunch of other stuff about other programs guessing what executable is running in a given process based on its argv[0], which is of course just deeply ignorant misuse of the value.

I mean, "the name" of the file that got loaded isn't even necessarily either well defined, or useful under any definition.

Re: Why bother with argv[0]?

#120

Post by citrin_ru »

JohnFen wrote: post #7

> Today however, disk space is no longer considered an issue On desktop machines, perhaps, but this is certainly not true on all platforms Linux runs on.

SSD relatively recently were not so big (compare to HDD with comparable price) and space is an issue on not so new desktops. I don't want to upgrade a notebook only because someone thinks that disk space is not an issue.

But of course this much more of an issue for embedded platforms like routers with OpenWRT.

Post reply on HN