dash

[Constantine Evans]

It should also be noted that even ignoring the speed increases in shell
scripts, using dash for /bin/sh should also cause significant speed
increases in python scripts making heavy use of os.system(), and ruby
scripts using system(), and so on, unless I am mistaken about their use
of /bin/sh.

Constantine Evans

Micah J. Cowan wrote:
> On Thu, Sep 14, 2006 at 04:18:46PM -0500, Rocco Stanzione wrote:
>> That reduces my argument to what it was before trying to find info on what 
>> POSIX had to say about it: that bash has proliferated so much, for so long, 
>> as the target of /bin/sh that the expectation has proliferated with it, not 
>> only in shell scripts that mistakenly say #!/bin/sh but in Makefiles (as in 
>> iptables, and GNU make doesn't inherit the SHELL variable - it's /bin/sh) 
>> where it's apparently also a mistake to use non-POSIX-compliant shell 
>> language, and likely in other places as well.
>>
>> Again, in Ubuntu packages, scripts (and Makefiles) can be and have been fixed 
>> to accommodate dash, but 3rd party applications not packaged by Ubuntu don't 
>> have this benefit and can be hard to diagnose when they break.  To complicate 
>> matters, even if you think you've fixed a problem by changing #!/bin/sh to 
>> #!/bin/bash at the top of a script, bash (still the default user shell) has 
>> cached sh as the way to call the script, and it will fail in the same way 
>> until you say something like "bash /path/to/script".
> 
> This is completely untrue. If you put #!/bin/bash in there, /bin/bash is
> what will interpret it.
> 
> At any rate, it's still certainly a bug on the part of those 3rd parties
> you mention, if they expect anything from sh beyond POSIX compliance.
> 
>> So, my opinion is that dash-as-sh is not worth the real and potential problems 
>> it causes.  I've only ever thought bash was slow-ish as a login shell, and 
>> that was due to bash-completion and my somewhat heavy .bashrc, and these 
>> aren't issues when running shell scripts.  Picking a few scripts basically at 
>> random and timing them with bash vs. dash, the biggest difference I've seen 
>> is 2ms, and those differences disappear altogether if I time them from within 
>> dash.
> 
> I don't understand your last sentence there, it doesn't make much sense
> to me for that to be true.
> 
> Your points are valid, but they were already known, and they come too
> late anyway. Much, much work has already gone in to fixing packages that
> had broken assumptions about /bin/sh.
> 
> The major reason, IIRC, that the change was approved, is that it tore a
> rather significant number of seconds off of boot time (init.d scripts).
>