Why is the file /bin/false so large?

[Loïc Grenié]

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