| > 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 softwareThen 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. |