Why is the file /bin/false so large?

[Seth]

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.
> 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
> 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). So, you'd get the hit for initializing a
process, attaching stdin/stdout/stderr, setting up a shell environment,
sourcing profiles (beware /etc/bash_completion and their kin) _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)
>         Loïc
>
>   
Seth

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20100209/a91e22da/attachment.html>