>Here's the deal.  As-is, the SPARC version of /bin/sh is 350K.  Take out
>libedit and job control et. al., and make it a minimal shell, and it's about
>200K.  The 75% code increase for all these added "features" makes a system
>that uses shell scripts heavily (read:  your average server type machine)
>perform less well.  Probably not much, but it does make a difference on,
>say, slow m68k and vax....  I'm actually compiling a stripped down sh for
>m68k to test speeds on a 68030-16.

Does it really make a difference?  I would expect the difference to be
nugatory, compared to, say, the amount of CPU time it takes to process
one more mistyped command.  :)

>If you want job control, line editing, history, why not just _use_bash_? 

Because it's much, much, larger, more badly written, and buggy.  Because
it has not one, not two, but at least *three* kinds of command line
history!

>It's not called the Bourne Again Shell for no reason.  No commercial unixen
>that I know of have extensive line editing and other features in sh, csh, or
>ksh--you're typically "expected" to install your own shell for the added
>Stuff.

Huh?  This is what actually prompted me to respond:

I have never heard of or seen a 'ksh' that did not have extensive line
editing features.  That is practically the *definition* of the difference
between sh and ksh.

>Most SVR4 variants even ship two versions of sh--'sh' and 'jsh', the
>former lacking job control, and the other supplied with it.  The reason for
>two versions?  Sh without job control loads faster!

Really?  I thought it was historical compatability.  (That, and in the
early SVR4, job control was crash-prone enough that...)

Anyway, the reason the POSIX sh has all of these features is that the
time when you are most likely to be stuck with "the shell" is the time when
you are most likely to be under stress, and making typos, and the time when
you are most likely to be in a hurry.  It's when the system is down.

It's also very nice to have some of the features (like history, job
control, and ${i%%bar}) standardized, because they make for more powerful
*and more efficient* shell scripts.

Would you care to bet on which is faster:
	1.  sh without "extra" features, spawning new subshell for sed or
	basename.
	2.  sh with "extra" features, using internal code for ${var%pat}
	substitutions.

Likewise, when you're trying to get a system up and running, which is
faster, using job control, or having your editor spawn another shell?

YMMV.  I like the moderately featurefull shells, although I think we've
reached a pretty plausible limit.  I'd honestly prefer line-editing to
be a feature of the tty driver, which could then provide continuity
between programs, but for now, I'm okay with using screen for that.

-s