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