coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Pádraig Brady
Subject: Re: That '[' file in /usr/bin
Date: Sun, 03 Mar 2013 10:53:17 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

On 03/03/2013 04:18 AM, Mike Frysinger wrote:
> 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.

This issue was mentioned here:
http://lists.gnu.org/archive/html/bug-coreutils/2009-11/msg00215.html

The problem with avoiding the aborts is that NULL is only
one of many invalid values for argv[0]

thanks,
Pádraig.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]