On Sat, 27 Sep 1997, Dustin Sallings wrote:

> 	I agree here, /bin/sh is used much more commonly for writing shell
> scripts than playing the role of an interactive shell in my experience.  Most
> of the time, it's tcsh or bash for people who want to hang out in a shell.

So you're suggesting that our standard user shell should be software
that is not only not included with the system, but is not compatible
with our licensing?  The fact that you prefer these shells doesn't mean
that there aren't many of us who can't stand csh(1)/tcsh(1L) and are
simply not willing to put up with the bloat and inconsistencies of
bash(1L)...  Has anyone elso noticed that most of the people who are
arguing to take important features out of sh(1) aren't _using_ it
anyways?

> To me, adding command editing and history features are about as useful as
> adding them to the perl or tcl binaries.  I'd much rather have a small, fast
> loading script interpreter.  Does the POSIX requirement actually say that

Fine.  Then build with -DSMALL.  A small change at worst.

> there has to be a /bin/sh with all these features?  It'd be nicer to have
> /bin/sh that's a normal /bin/sh (no job control, no editing, etc...) and
> maybe another one (even bash) for people who want to hang out in it.

Posix 1003.2 does, in fact, require command line history and editing.
The suggestion of having fat and thin versions of the shell is valid, I
suppose (cf Solaris with /sbin/sh (static) and /usr/bin/sh (dynamic)).

/bin/sh could be a fat shell (perhaps even a link to /bin/ksh, or pdksh
(the ksh we use) compiled in POSIX compatibility mode.  /sbin/sh would
be a small, static shell.

--
				Jim Wise
				jim.wise@turner.com