* Michael Matz <matz@suse.de> [2010-03-23 14:49]:
I repeatedly hear this claim, seldom to be followed up by credible numbers. And of course: when does it actually matter, even if some other shell was faster? (I already can feel the answer being "but booting will be so much faster then", which is wrong).
Well the "claim" acutally comes from the bash maintaines, read bash(1) BUGS. One example is startup time, try libmicro's system benchmark /usr/lib/libMicro/bin/system -E -C 200 -L -S -W -N "system" -I 1000000 with /bin/sh as a link to ksh or dash and empty .profile/ENV. dash is 2,5 times and ksh93 is still 1,5 times faster. I have anecdotal evidence that pattern matching while processing textfiles is significantly slower in bash compared to ksh93/dash. Furthermore, ksh93 offers a lot of builtins for standard commands which are significantly faster than forking and execing and which could be taken advantage of.
Comments, Suggestions?
Yes, I think we shouldn't have such policy. I have an alternative proposal: make all scripts hardcode /bin/bash. It's easier to implement and check for violations, we reduce choice (and therefore bug sources), bash is actively maintained, and the constructs it gives in addition to POSIX are visually more pleasing, and more expressive, hence will lead to less bugs in scripts written by inexperienced shell programmers.
I also think you underestimate the work that would be required to implement your policy, first it's a huge amount of work upfront (and not all violation can be found via automatic means), with the potential of introducing as many bugs as there are changes. But what's worse is the constant amount of work that needs to be invested afterwards, just to keep bashisms to crop up again. At least for autoconf it's not trivial, and that is only one package.
And local patches will make us deviate from upstream if the scripts originate there. For that reason alone my suggestion of hardcoding bash wasn't meant serious.
I mean, if the original authors of the scripts decided that they want to invest that work, fine, more power to them (because in the abstract I agree with the wish of using only POSIX sh constructs in scripts claiming to use /bin/sh), but creating a policy that would force us to invest that work for the dubious value of purity, no, thank you.
It will be some work to implement this but this can take place gradually and does not need to happen overnight. This policy is not intended for third party scripts, that is upstream scripts would only need to be changed from /bin/sh to /bin/bash and that should not be too hard to patch or to get into upstream projects. Ubuntu has been using dash as /bin/sh since 2006 and Debian is preparing to do the same for Squeeze, so a lot of the required changes have already been incoroporated into upstram projects. An don't forget that on Free/Net/OpenBSD /bin/sh has always been ash, on Opensolaris /bin/sh is a linked to ksh93. For our own scripts it would only mean that we enforce clean coding practices which is IMHO a good thing and it is also not too hard, you just need test them with dash instead of bash. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org