Re: That '[' file in /usr/bin

[Mike Frysinger]

On Saturday 23 February 2013 15:56:20 Eric Blake wrote:
> On 02/23/2013 10:25 AM, Salvador Girbau wrote:
> > Hi all,
> > would it be possible to replace /usr/bin/[ with a symlink to
> > /usr/bin/test ?
> 
> Not really.  Although [ and test are compiled from the same sources,
> they are compiled with different macro definitions, and have different
> behavior (namely, whether --help is supported, and whether a ] must
> appear as the last command line argument).  GNU Coding Standards
> recommend that programs never inspect argv[0] as a means of dynamically
> changing their behavior, and coreutils follows this rule by compiling
> two separate binaries with the two different behaviors, regardless of
> what the resulting binary finally gets named.
> 
> If you want to go for minimal binary size, then busybox is a better
> project - that project has intentionally decided to base behavior on the
> name of argv[0], and hence can symlink both [ and test to the same
> busybox binary (along with a host of other utilties all crammed into one
> super-binary).  But coreutils will not be adopting that approach.

an example of why argv[0] can be bad: doing execve with argv[0] set to NULL is 
not an error, and apps that rely on argv[0] will usually segfault immediately.  
or they won't be able to figure out how they're supposed to behave.

for example:
$ cat test.c
#include <unistd.h>
int main(int argc, char *argv[]) {
        char *args[1] = {0};
        return execve(argv[1], args, 0);
}
$ gcc -Wall test.c
$ ./a.out /bin/dmesg
<works>
$ ./a.out /bin/ip
<segfault>
$ ./a.out /bin/mv
<aborts>

personally, i find it a bit ironic that a lot of GNU apps (including coreutils) 
simply abort() themselves when argv[0]==NULL considering the project's hard 
line position about not relying on argv[0] for behavior.
-mike

signature.asc
Description: This is a digitally signed message part.