Re: mksh import

[christos%astron.com@localhost (Christos Zoulas)]

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
>> shells?
>> 
>> Thanks,
>> 
>> -- Alex -- alex-goncharov%comcast.net@localhost --
>
>Here is a link to a presentation given at NLUUG several
>years back:
>
>https://docs.google.com/present/view?id=dqwmc5b_0fpv6h5

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.

christos