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.
Given that 'alias' is in POSIX, would a combination of
(a) the hypothetical non-argv0 busybox being discussed, and
(b) a POSIX shell of the maintainer's choice, with built-in aliases for 'ls=busybox ls'
be sufficient to make the system POSIX complaint?
aliases are not inherited by subprocesses unfortunately! so the alias solution would not work when a shell script launches other shells cripts. It wouldn't work in a wide range of other scenarios too like Makefiles, bespoke build tools, binary executables that do execve("/usr/bin/cmp", ...) etc.
Re:Why bother with argv[0]?
by yellowapple on Friday September 06, 2024 @03:15PM
(#41468909)
In addition to the already-raised issue of subprocesses not inheriting aliases, I'd also be worried about aliases inherently being specific to particular shells. I'd hate to have to redefine those aliases for sh, csh, zsh, fish, and Lord knows what else. It'd also be an issue for invoking those tools without going through a shell in the first place - as is common for programs launching external programs as subprocesses.
That's indeed why I personally don't use shell aliases at all, instead opting for actual shell scripts in my $PATH. Those will work no matter what shell I'm using (if any).
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 sparked this debate.
This is a very strange way to deflect concerns about quality of the article!