[deleted]
Why bother with argv[0]?
121–130 of 277 posts
Re: Why bother with argv[0]?
#122Earlier quoted context omitted.
These are all very realistic examples. Should they happen? No, but reality is messy and imperfect. The crappy software you describe would not exist if there were great solutions in this space.
Yes, they are realistic. No you shouldn't change your system to satisfy clown development dynamics. And just as a warning, if you insist on doing so, the rules will get ever more complicated. Expect to not be able to achieve anything at all very soon.
If Crowdstrike is an example, then that's not true. Instead, success is not gated by rule quality, and you can get to global scale without a signal as to whether your rules are actually good or effective. And then someone publishes a new template and boom, Delta grounds their planes for days.
Re: Why bother with argv[0]?
#123It’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, which was really an anomaly built into C, the culture of C, or both because C++ books still read this way. C had so many half-baked things, such as an otherwise clean parser that required access to the symbol table. And of course a general fast and looseness which lead to the buffer overflow problem.
There were other languages which failed to solve the systems programming problem like PL/I and Ada, not to mention ISO Pascal which could have tried but didn’t. (Turbo Pascal proved it could have been done.)
People took until 1990 or so to be able to write good language specs consistently, so we can forgive Unix but boy is it awful if you look closely at it. On the other hand, IBM never did make a universal OS for the “universal” 360, yet Unix proved to be adaptable for almost everything.
Re: Why bother with argv[0]?
#124Earlier quoted context omitted.
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
Surely you mean
#!/bin/sh
exec /bin/busybox cmp "$@"Re: Why bother with argv[0]?
#125Earlier quoted context omitted.
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?
On Unixes it doesn't matter if /usr/bin/cmp is a script or a compiled binary. If the script has correct shebang, kernel takes care of executing it.
Shebangs are not part of the UNIX specification. What happens if an executable starts with `#!' is implementation-defined.
Re: Why bother with argv[0]?
#126Earlier quoted context omitted.
No you make this script: #!/bin/sh exec /bin/busybox cmp And place it at /usr/bin/cmp
Surely you mean #!/bin/sh exec /bin/busybox cmp "$@"
`#!/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.
Re: Why bother with argv[0]?
#127I 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.
Re: Why bother with argv[0]?
#128Earlier 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.
Don't do this - if you (reliably) want the path to the current executable there is no portable way to do it, but on Linux you need to readlink /proc/self/exe and on MacOS you call _NSGetExecutablePath. I forget the API on Windows.
Note though that both of these solutions are racy and so should not be done if "someone symlinking really fast and swapping the binaries" is in your threat model. Linux proc/self is safe though, just not the result from readlink.
Re: Why bother with argv[0]?
#129Earlier quoted context omitted.
Surely you mean #!/bin/sh exec /bin/busybox cmp "$@"
`#!/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?
Re: Why bother with argv[0]?
#130So 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…
For busybox/toybox the argv[0] thing is great, and seems to be the prime example of why argv[0] shouldn't go - yet it is a bit of an anomaly in how argv[0] is used. If there really is a need for having one executable that comprises multiple commands, is `busybox whoami` instead of `whoami` so much more effort? To me, that would make more sense in terms of what is going on; aliases could be used if one-word commands a…
`busybox whoami` is probably fine, but having to write `busybox ls`, `busybox grep`, `busybox cp` etc. would get tedious quickly.
Shell aliases don't solve all problems, even if you do:
alias rm="busybox rm"
alias xargs="busybox xargs"
# etc.
But the main problem with this approach is that POSIX and LSB require certain binaries to be available at certain paths. When they're not, most shell scripts will just break.
The minimal standard solution is probably to create shell scripts for all of these, e.g. in /bin/ls:
#!/bin/sh
exec /bin/busybox ls