Hi, On Tue, 23 Mar 2010, Guido Berhoerster wrote:
Rationale ---------
* Speed: bash is slow, allowing scripts to run on other shells such as dash or ksh93 may lead to speedups in certain situations
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).
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. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org