* Michael Matz
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.
Please? With -I 20000, so it takes some measurable time: pdksh: 13.6 seconds; 13501 usecs/call ash: 12.7 seconds; 12715 usecs/call zsh: 11.6 seconds; 11583 usecs/call ksh93: 3.2 seconds; 3139 usecs/call bash: 3.1 saconds; 3176 usecs/call
That's on a 11.1 (and I don't have dash, only ash). I'm not impressed. But the above numbers don't mean that I would be opposed to making for instance zsh the default shell, even though it is four times slower than bash. Simply because system(3) isn't all that important, if you're spending more time in system(3) than in actual data processing you're doing something wrong anyway. That doesn't mean that system(3) should be arbitrarily slow, but it means that it's not a very large factor to consider.
# /usr/lib/libMicro/bin/system -E -C 200 -L -S -W -N system -I 20000· dash: 1.21781s; 1200.16680 usecs/call ash: 2.17763s; 2145.16600 usecs/call bash (LC_ALL=C): 3.40030s; 3354.16580 usecs/call bash (LC_ALL=en_US.UTF-8): 5.57932s; 5506.36800 usecs/call ksh93 (LC_ALL=C): 6.00663s; 5924.16780 usecs/call ksh93 (LC_ALL=en_US.UTF-8): 6.17549s; 6102.36820 usecs/call Startup time does e.g. matter for my monitoring scripts and CGI scripts. And it is just one example, another more relevant one which I have mentioned in this thread is subshell performance. And finally -- performance was not my _main_ and _only_ rationale for this.
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.
That is an advantage, indeed.
It also has shcomp :)
Well, if you want to work on that, be our guest. If you can convince the· package maintainers to take patches, or upstream to integrate them (even· better) all is fine. I'm only against making it a policy, which suddenly· would force other people to invest work. That might be okay if the· advantages are large and obvious, but in this case they aren't.
I am interested in this or I wouldn't have brought it up here. It could be mandatory for newly added scripts only, otherwise it wouldn't make sense to me to fix things. Furthermore, it would probable not be that much work for maintainers to check whether upstream scripts work with /bin/sh when they upgrade packages and to patch /bin/sh to /bin/bash if necessary.
I trust that that one is more capable than our ash? : % /bin/ash -c 'i=0; j=$((i+1))' arith: syntax error: "i+1"
openSUSE ash is ancient. This and other issues have been for some time. If you're interested in the differences, see http://www.in-ulm.de/~mascheck/various/ash/
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.
Aha. And that's relevant exactly how? After all you said you were talking about internal scripts, not upstream ones?
It is relevant for build systems which has been brought up here. Debian's efforts also have resulted in changes upstream.
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.
See above, if you want to work on that, jolly good.
Working on it only makes sense if maintainers accept patches for such changes. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org