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

131–140 of 277 posts

Re: Why bother with argv[0]?

#131

Post by mariusor »

Hizonner wrote: post #119
mariusor wrote: post #111

Earlier quoted context omitted.

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…

Then it looks like I'm terrible at reading comprehension today, I understood you were arguing the same thesis as OP. Apologies, again. :)

Re: Why bother with argv[0]?

#133

Post by oguz-ismail »

teddyh wrote: post #129
oguz-ismail wrote: post #126

Earlier quoted context omitted.

`#!/bin/sh' makes this less portable than it could be, if /bin/sh doesn't exists on my system it won't work, for example. Remove that line and it'll work everywhere.

If /bin/sh does not exist, what in the world is executing the shell script?

The shell, of course. It just might not be (because it doesn't have to be) located in /bin.

Re: Why bother with argv[0]?

#134

Post by astrobe_ »

dcminter wrote: post #14

This lost me at "goes against modern design principles" without citing what principle(s) the author had in mind that would proscribe it.

the Modern principle prescribe that one should never use software that's older than yourself. Some cults even prescribe that that one should not use a framework longer than you would wear a pair of socks.

Re: Why bother with argv[0]?

#135

Post by hnlmorg »

fallingsquirrel wrote: post #20
mistercow wrote: post #8

Earlier quoted context omitted.

Also if you want a program to call itself, which is sometimes useful, this way lets you actually call the same program, rather than assuming the name and path.

You can do this without assuming the name by execing /proc/$PID/exe. Then you're not vulnerable to the argv[0] spoofing described in the article. (But of course since argv[0] does exist, you should set it properly and pass through your own argv[0] unchanged.)

That’s Linux only. Wouldn’t even work on macOS, which would likely be a significant number of your users.

Re: Why bother with argv[0]?

#136

Post by wang_li »

SoftTalker wrote: post #45
mistercow wrote: post #8

Earlier quoted context omitted.

Also if you want a program to call itself, which is sometimes useful, this way lets you actually call the same program, rather than assuming the name and path.

There's no guarantee that the name and the path are still the same executable that is running, or that they even exist anymore.

In most of the variants of exec*() there are separate arguments for the thing to be executed and the *argv[] list. Argv[0] being the executable is just a convention. In perl $ARGV[0] is the first positional parameter. In

    $ perl myscript.pl a b c
$ARGV[0] is "a".

Re: Why bother with argv[0]?

#137

Post by teddyh »

oguz-ismail wrote: post #133
teddyh wrote: post #129

Earlier quoted context omitted.

If /bin/sh does not exist, what in the world is executing the shell script?

The shell, of course. It just might not be (because it doesn't have to be) located in /bin.

I’m pretty sure that /bin/sh is mandated by POSIX.

Re: Why bother with argv[0]?

#138

Post by ahoka »

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…

“That is simple enough to solve (add an API call to update _your own process name_ or at least update your own process 'title' which interfaces like ps/taskman can use accordingly)“

We could call it setproctitle, or something. \s

Re: Why bother with argv[0]?

#139

Post by zabzonk »

PaulHoule wrote: post #123

It’s part of the shambolic world of Unix and C. But “worse is better!” A good language spec is laid out in a way that reads from front to back with minimized circularity. See Common Lisp, Java, Python, etc. As a kid in high school checking out Unix manuals and implementing many Unix tools in https://subethasoftware.com/2022/09/27/exploring-1984-os-9-o... I struggled with K&R because of the circularity of the book, wh…

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?

Re: Why bother with argv[0]?

#140

Post by croes »

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…

It's easy to call something a mistake in hindsight.

You could argue the mistake was done elsewhere so this feature could be abused.

Post reply on HN