dash

[Micah J. Cowan]

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).

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/