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

211–220 of 277 posts

Re: Why bother with argv[0]?

#211

Post by adw »

gary_0 wrote: post #84
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…

Yeah. The whole point of busybox is to provide the POSIX commands in one compact executable. Making things work any other way defeats the entire purpose of busybox.

In other words: `busybox` is primarily an implementation of a _standard library_ and only secondarily a command line tool, so it _must_ use the standard names.

Re: Why bother with argv[0]?

#212

Post by scintill76 »

PaulHoule wrote: post #159
zabzonk wrote: post #139

Earlier quoted context omitted.

i may have missed it, but where does the C Standard say anything about access to a symbol table? or even if such a thing exists. and as for IBM i managed to use all sorts of OSs in VMs on IBM hardware back in the 1980s. Which did you have problems with?

The parser in C has to keep track of the symbol table to handle cases like typdef int myint; myint x; which is unusual among programming languages. Sure I used VM on IBM hardware in the 1980s and it was great. I also used timesharing systems on the PDP-8 (what atrocious hardware!), the PDP-11 and the PDP-10/20 in the 1970s. Although the 360 was superior in so many respects (except for the slow interrupt handling) it…

I don’t know that ‘;’ is ambiguous in C. (For this expression it seems the parser could be confident the left is a type name, and raise an error later if not.) I’d be interested in seeing a counter-example for that simple of an expression. There are more obvious examples IMO here: https://eli.thegreenplace.net/2007/11/24/the-context-sensiti...

Re: Why bother with argv[0]?

#213

Post by Maxatar »

rzwitserloot wrote: post #58
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…

That seems unnecessarily harsh. I don't think that's the gist of the article, but the throwaway suggestion of 'just make lots of copies, who cares about diskspace' is insufficient and thus distracts. It's.. a single line about solutions in an article that isn't _about_ solving problems, it's about highlighting a problem exists and that it's worth solving. I read the article more as: There is __often__ no good reason…

>Show the actual file path, and always an absolute one

There are numerous reasons why this is not desirable, for example knowing whether an application was called from one symbolic link or a relative path dictates what that application's working directory is.

Re: Why bother with argv[0]?

#214

Post by im3w1l »

duped wrote: post #206
vlovich123 wrote: post #188

Earlier quoted context omitted.

Hmm... I generally have so many issues with chdir (e.g. someone gives you a relative path to a file you need to read and now that's screwed up because you did a previous chdir) that I just avoid all use of it in the first place. Generally don't run into chroot all that often these days & docker gives you a fully virtualized environment where if a relative path is garbage then you may have other problems too (e.g. giv…

It's very common for daemons/servers to chdir("/") at the top of main. Relative paths sent by clients getting broken is a feature, not a bug. (In fact I just fixed a bug related to this an hour ago because a relative path was not being canonicalized before being passed to the daemon I'm working on and it caused a file to be written to the wrong place). There's no way create a process such that /proc/self/exe is incor…

For the c-programmer adding a dependency is so difficult that he would rather use a roll his own 99% solution than use a library. It does protect him from supply chain attacks, I suppose.

Re: Why bother with argv[0]?

#215

Post by im3w1l »

Arch-TK wrote: post #68
SoftTalker wrote: post #48

Earlier quoted context omitted.

One other historical reason for this (also the reason that older unix utilities tend to have such short names) is that people often interacted with unix machines over slow terminals or even paper teletypes. Typing "rm" instead of "remove" or "reboot" instead of "systemctl --reboot" was legitimately more convenient.

I mean, it's still more convenient to type `rm` rather than `Remove-Item` when doing day-to-day computer tasks on your computer (yes I'm one of those people who lives in a terminal). It's also certainly better from a readability standpoint to have `Remove-Item` rather than `rm` in a script. Likewise, I would much rather type `ls -Al` rather than `ls --almost-all --long-listing` (N.B. --long-listing is not the long op…

The best name from a readability standpoint is the shortest name you know by heart. So you might actually want to consider who your intended audience is.

Re: Why bother with argv[0]?

#216

Post by jenscow »

soneil wrote: post #173
pzmarzly wrote: post #101

Earlier quoted context omitted.

Not an author, but there's a good alternative. If busybox was edited to ignore argv[2], then applets could be called via shebangs, instead of symlinks: $ echo '#!/path/to/busybox echo' > myecho $ chmod +x myecho $ ./myecho 123 ./myecho 123 Right now this doesn't work properly, because "./myecho" (argv[0]) gets placed into argv[2] of the process. Otherwise, this technique IMHO is better than symlinks: - Each applet us…

I was going to say it'd be easier to have a single script, eg #!/bin/sh busybox $0 $@ and then every command required could just be a hardlink to the same script, instead of replicating it over and over again for hardcoded command names. Then I realised the whole point is to posit a world where $0 doesn't exist, and we're not allowed to be clever about it.

In such a world, shells would probably have something like a $SCRIPT_NAME to work around this.

Re: Why bother with argv[0]?

#218

Post by dwattttt »

toast0 wrote: post #186
wongarsu wrote: post #167

Earlier quoted context omitted.

> On a unix filesystem, a file that's hard linked with multiple names has no single 'actual name' The same is true for hard linked files on Windows. That never stops Windows from showing you a path. There is almost always an "obviously right" path (the one used when opening the file). And if you lost track of that, deterministically choosing one of the possible paths is almost always more user friendly than just chow…

> There is almost always an "obviously right" path (the one used when opening the file). The path used while opening a file is easy to get confused. If your cwd changed names or was deleted since you entered it, and you open an executable with a relative path, what is the "obviously right" path then?

In context, there's still a right answer; the absolute path used to run the process should always be right, because the Windows locks the file (I'm sure with enough effort this can be made wrong, but I'm also sure that's not trivial).

Really, this discussion just shows the question is the problem; if you're asking "what path was used the launch the process", that's easy to keep track of & always be right. If you're asking "what is the path right now to the file that launched the process", maybe that has no answer.

Re: Why bother with argv[0]?

#219

Post by kelnos »

> From a 2020s standpoint, this seems highly undesirable, as it makes software less predictable and goes against modern design principles.

Says who? I'm not aware of any modern design principles that say anything about this sort of thing.

> argv[0] is ignored (mostly)

Pretty much any program I've written that has a --help option uses argv[0] to print out the usage string, i.e.:

    printf("%s [--some-arg] FILENAME\n", argv[0]);
> First off, argv[0] can be used to fool security software

Then that security software is poorly written. On Linux, the correct way to find the binary of a running process is by calling readlink(2) on /proc/$PID/exe. Assuming security software like this is going to have a lot of OS-specific code, it seems fine to me to expect they use it (and then have to do other things on other OSes).

> Another argument against this design is that if you have two programs that are so similar that it pays off to consolidate them into a single file, is there really a need for two separate programs/program names?

The author is talking about shutdown and restart being symlinks to systemctl on systemd-based systems. But what about something like busybox? busybox contains hundreds of programs, all conveniently in a single, statically-linked binary. On my system it's about 800kB. While I agree that even 250MB is not a big deal for most systems these days, it certainly is a problem for, say, a WiFi router that only has 8MB of flash.

> Ultimately, nobody wants to be bothered by argv[0].

False. I find it useful, and am not "bothered" by it at all. And I suspect security folks aren't really bothered either: the ones that actually know what they're doing look at /proc/$PID/exe when they want to find the binary backing a PID.

This article is kinda lame, and it seems like the author's objections are mostly based on ignorance.

Re: Why bother with argv[0]?

#220

Post by kelnos »

cxr wrote: post #170
alerighi wrote: post #151

Earlier quoted context omitted.

Well that would be inefficient. For each command you run the kernel has to read the file, detect that it has a shebang, parse the shebang line, and then finally load the actual executable in memory. That could be a performance problem, since busybox is used typically in embedded systems that doesn't have a lot of resources: imagine a shell script that runs a command in a loop, it has to do a lot of extra work. Finall…

> Well that would be inefficient. For each command you run the kernel has to read the file, detect that it has a shebang, parse the shebang line, and then finally load the actual executable in memory. Those that exist today would, but no kernel would have to work like that. Once you've agreed that monolithic kernels have merits, you've accepted that the kernel can do whatever it wants to make this efficient—including…

> Those that exist today would, but no kernel would have to work like that.

That's a pretty weird argument. "Yes, what you say is completely correct, but let's imagine a world where you were wrong."

We have what we have, today. We should form conclusions and make decisions based on things that exist, not on things that we might dream up.

Post reply on HN