[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ash vs. bash

On Sat, Jul 24, 1999 at 10:42:07AM -0400, Michael Stone wrote:
 >That's simply not adequate. There are not just syntax differences
 >between the shells, there are logical differences as well. That's why I
 >refuse to screw with /bin/sh on production systems even though I use ash
 >on my own machine: there are almost certainly scripts out there with
 >little-used code paths which will behave differently under ash than
 >under bash, _even though they are syntactically valid in ash_. There's
 >too much uncertainty at this point to change the default. (Although I
 >agree that if _I_ change /bin/sh, bash ought to keep its hands off it.)

But if it does, then those rarely used scripts that use bashisms,
that happened to work because #!/bin/sh was actually bash, will fail
on you. That is why I say that leaving the link alone is probably not
enough. Well-done system configuration scripts, makefiles and that
should always avoid assuming than /bin/sh offers features other than
the basic Bourne ones. Pre- post- scripts in /var/lib/dpkg/info/ that
use non-bourne features do not help with achieving a better policy.
I agree with you that unless someone make sure that all Debian system
scripts use pure-bourne code it is probably better not to fiddle with
/bin/sh, but that also means that upgrading bash _will_ have to reset
the link, because otherwise something could break. Anyway, I think that
by deciding not to fix it now, is likely to cause it to pop up again 
in the future, when even more scripts will depend on bash.


Carlo Strozzi       PGP Public Key fingerprint :
ED 4A 7A 6C 88 66 1B 34  06 14 FC 2E C7 EA F2 EE

Against software patents:
http://www.freepatents.org , http://no-patents.prosa.it

Reply to: