Re: mksh import

[David Laight <david%l8s.co.uk@localhost>]

On Fri, Dec 31, 2010 at 09:15:47PM -0500, Alex Goncharov wrote:
> Let me try to offer you a user's perspective.
> 
> I spend a significant part of my work day at shell prompts, working
> with various OSes.  Another noticeable part of my time is spent
> writing shell scripts.
> 
> And, any day of the week, I could say, "Thank God, Bash exists!.."

Actually I've written quite a lot of scripts and use long command lines,
(and have done so for many, many years) and rather wish that bash
didn't exst!

> I don't care much (remember, I am a user, not an OS provider, which
> would be a different story) about the strict /bin/sh or POSIX.N
> compatibility.  Neither I, nor most of the (very skilled) people
> around myself would be able to correctly explain what that means.

If you want to write scripts that are portable between machines, you
need to ensure that you only use the 'posix' features.
Unfortunately bash doesn't implement some of them, and has a lot of
non-standard extensions that really just cause portability issues.

If you really want portability you need to restrict yourself to the
'traditional' bourne shell (eg /bin/sh on solaris). That doesn't
stop you writing complex scripts, but does require lateral thought
to avoid the costs of running 'expr' (etc).

> With Bash, I have a uniform and extremely efficient environment for
> both command line manipulation and scripting;

Bash is a very slow shell for running scripts - so not efficient!

> I don't have to use one
> shell for the former and another for the latter -- thus, I can perfect
> my shell mastery all the time, naturally.  I can use (or build) Bash
> on any of the many platforms I work with -- and the same version of it
> will behave the same elsewhere.

> It also helps that Bash is:
> 
>   * Constantly evolving, adding new powerful features;

That goes against your statement of 'uniform' - since if you find start
using any new feature, your scripts will fail to work on any old
systems.
Additionally new fetaures tend to have slight side effects on some
(maybe obscure) scripts - which is probably why Sun never updated /bin/sh

>   * Extremely well documented;

Hmmm... I doubt it, certainly the 'man' page is as terse as ever and
won't describe any of the finer points (and maybe stop you doing things
which shouldn't really be allwed).

>   * Probably (a.k.a. "in my experience") has fewer bugs than Ksh
>     implementations.

Netbsd's ksh doesn't get that much attention (neither will other OS's
versions these days), so that is likely.
Bugs in the shell parses can be difficult to fix without creating
larger problems elsewhere, this is partially due to the add-hock nature
of parts of the language (which are, in some cases, defined to match
the historic behaviour).

> These days I only rarely have to use Perl to do something I cannot
> easily do in Bash with a small mix-in of Awk and Sed.

Perl? the only people who use perl for general scripting started on
windows - where there isn't a shell (actually windows is only usable
with the cygwin tools installed!)

> Excluding Zsh, which I have never used, would I be able to do that
> kind of scripting in any other shell?  Maybe in Ksh... some of
> it... struggling with bugs and learning more and more "don't do this"
> rules.

Unless you are doing some very obscure (or broken!) things netbsd's
/bin/sh (which is based on ash) should work fine - and as well as
most versions of ksh.
bash has some extensions, but for portability they are best avoided.

> Would any of those shell lend me an interactive environment with at
> least 50% of what Bash gives me?  No way.

You still haven't said which bash features you consider so important.

FWIW many of the bugs in netbsd's bin/sh are in correctly parsing
things like "${foo:-"}"}"
(that one may be ok!)

        David

-- 
David Laight: david%l8s.co.uk@localhost