[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: mksh import
In article <BLU104-DS9CA5D6D0392794CAFA792A50C0%phx.gbl@localhost>,
Dad - Kent - <pobox0123%hotmail.com@localhost> wrote:
>>From: "Alex Goncharov" <alex-goncharov%comcast.net@localhost>
>>Sent: Tuesday, January 04, 2011 9:16 PM
>> ,--- You/Kent (Tue, 4 Jan 2011 20:41:49 -0600) ----*
>> | Ksh93 has shown itself to be much more efficient than other shells.
>> | IMO mksh is not on par with ksh93 in performance
>> Any pointers to performance comparisons and/or test cases, for any
>> -- Alex -- alex-goncharov%comcast.net@localhost --
>Here is a link to a presentation given at NLUUG several
All of that is very interesting, but once you "ln /bin/ksh93 /bin/sh"
you've destroyed any chance of keeping your shell scripts portable
to the posix /bin/sh subset. It is very easy for people to start
using ksh93 without even knowing about it. Recently I had to deal
with a migration from suse to ubuntu where in suse /bin/sh == bash
and in ubuntu where /bin/sh == dash. It was not pretty and even
trivial things broke like 'if [ "$FOO" == "bar" ]' vs. 'if [ "$FOO"
= "bar" ]'.
It is always very tempting for an implementor of an interpreter to
add/change features to improve the language. This can have varying
degrees of success, depending on the necessity of the features,
backwards compatibility, number of implementations, and support
from a standards committee.
In this case, for most of the advanced shell features there is no
committee support yet, and there are just too many /bin/sh
implementations out there which makes it difficult to write a
portable script and delays the acceptance of the advanced features.
Now, if you don't care about portability, that is not an issue.
Main Index |
Thread Index |