Why bother with argv[0]?

Legitimate uses of argv[0]

• Many commenters argue argv[0] is fundamentally just another argument and widely useful:
  • Multi-call binaries (e.g., busybox, toybox, Android tools, rustup, git, clang, coreutils-style shims) dispatch behavior based on the invoked name.
  • Shells use it for “login shell” behavior (leading - in argv[0]).
  • Programs use it in help/error messages and examples, sometimes stripping the path or using __progname.
  • Some tools use it to set or display process titles (with OS APIs like setproctitle, prctl, or language-level wrappers).
  • Scripts and binaries sometimes use it (or related mechanisms) to locate resources relative to the executable.

Busybox and compatibility

• Busybox and similar toolsets are repeatedly cited as strong counterexamples to the claim that argv[0] is “legacy” or unnecessary.
• Removing or restricting argv[0] would break POSIX/Unix expectations, existing scripts, and many systems that rely on multiple names resolving to one binary.
• Suggestions like “just use busybox cmd” or wrapper scripts are criticized for overhead, non-POSIX behavior, and incompatibility with existing binaries and scripts.

Security concerns and criticism of security tooling

• The article’s core concern: attackers can spoof argv[0] to fool logging, detection, or EDR tools, or use very long values to disrupt telemetry.
• Many replies say this reflects flawed security software, not a design flaw in argv[0]:
  • Correct process identification should use OS facilities (/proc/*/exe, executable-path APIs, mapped binaries), not trust argv[0].
  • Treat argv[0] like untrusted user input; escaping/quoting in logs is the responsibility of logging tools.
• Some agree the call site’s ability to set argv[0] is abusable, but think retrofitting restrictions would break too much.

Executable path vs. invocation name

• Strong consensus: argv[0] is the invocation string, not a reliable executable path.
• Several platform-specific APIs for getting the actual executable are mentioned and preferred when that’s the goal.
• There is debate over using argv[0] to re-exec oneself; critics highlight chdir/chroot/PATH issues, others say it’s acceptable in controlled contexts.

Disk space, performance, and “modern design principles”

• Claims that “disk space is no longer an issue” and that argv[0] violates “modern design principles” are widely rejected.
• Commenters cite embedded systems, routers, containers, and large images as cases where multi-call binaries and size savings still matter.