Why is the file /bin/false so large?

[Justin Gruenberg]

I want to appoligize first, because this is probably going to be a top
post. I've been drinking.

Yes, we could make a smaller true or false. Its an exercise left to
the entry level CS student.

However, there are standards. They were followed for the version
Ubuntu includes. It includes some cruft that's not normally used.
But, how often are these utils actually called?  I doubt its enough to
really put a lot of thought into replacing them. I'd bet if this is
really a bottleneck in your scripts, you should post them and the
experts around here could give some pointers to make things faster.

On 2/10/10, Loïc Grenié <loic.grenie at gmail.com> wrote:
> 2010/2/9 Seth <ubuntu-users at sehe.nl>:
>> Loïc Grenié wrote:
>>
>> 2010/2/9 Mihamina Rakotomandimby <mihamina at gulfsat.mg>:
>>
>>
>> Loïc Grenié <loic.grenie at gmail.com> :
>> #!/bin/sh
>> exit 1
>>
>>
>>>> This will launch one "sh".
>>>> Is it really smaller in footprint?
>>>> I dont know.
>>
>>
>>>    Yes and no, sh/bash/dash is probably already in memory for some
>> >  (many) shell-scripts.
>>
>> The same thing goes for /bin/false _and_ a decent shell will cash the
>> inode
>> for it.
>
>     Indeed. I've never said the contrary. But you can still make /bin/true
> and
>   /bin/false smaller.
>
>>> Since most of the memory
>>
>> That is a daring statement, especially for something involved like, say
>> bash. I'd be willing to be bet that it is 50% at most that is shared.
>> Don't
>> forget that a silly thing like stacks or libreadline heap can really ruin
>> the shared mem ratio
>
>      Not if the same shell is already loaded into memory.
>
>>> is shared between
>>>   processes (read-only memory of processes and libraries is shared),
>>>  memory footprint won't change much whether you launch this script
>>> or not.
>>
>>
>> Only if the shell could 'optimize out' the fork/exec to the shell process.
>> I'm pretty sure that cannot be allowed under any POSIX compliant shell. I
>> have even been lead to assume that the interpretation of #! is actually
>> more
>> of a _kernel_ loader feature than a shell feature (I might be mistaken
>> here).
>
>     This is a time optimisation against a disk optimization (#! is indeed
> done
>   by the kernel).
>
>> So, you'd get the hit for initializing a process, attaching
>> stdin/stdout/stderr,
>
>     Same for binary /bin/false
>
>> setting up a shell environment, sourcing profiles
>> (beware /etc/bash_completion and their kin)
>
>     I don't know whether bash parses its profiles for scripts (csh does not
>   for instance)
>
>> _parsing_ the command line and then interpreting the commands.
>> That is a slew of overhead even comparing with GNU coreutils/false;
>>
>>>      Whether this is a sensible idea or not, I leave it to more
>> >  knowledgeable people.
>>
>>
>> I bet, if you wanted to 'script' your way out of a memory/disk footprint
>> and
>> make a ridiculous sacrifice in the CPU/mem footprint instead you'd have to
>> go perl/python/ruby it in a holistic fashion (so avoid the execs and
>> instead
>> use language-native constructs)
>
>    CPU footprint yes, memory footprint no. Time:
>
> $  time zsh -c 'repeat 10000 /bin/false'
> zsh -c 'repeat 10000 /bin/false'  1,37s user 4,85s system 96% cpu 6,447
> total
> $ time zsh -c 'repeat 10000 /bin/sh -c :'
> zsh -c 'repeat 10000 /bin/sh -c :'  5,92s user 7,98s system 97% cpu 14,285
> total
>
>   So yes it's slower (twice the time) but "ridiculous sacrifice" is
> left to the user
>   to evaluate.
>
>       Loïc
>
> --
> ubuntu-users mailing list
> ubuntu-users at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
>

-- 
Sent from my mobile device