🚀 go-pugleaf

> = David Elliott
>> = Me

>>I think csh compatibility should not be a goal.  Bash is not csh; it's not
>>even a csh clone.  I think ksh compatibility should be a goal (the useful
>>features of ksh, that is).

>If that's your reasoning, then get rid of >&.  A half-done job confuses
>users trying to switch over.  Is this confusion your goal?

First of all, what I want doesn't mean nearly as much as what Brian wants.

I don't think >& should have been in there in the first place.  It looks
like something different to people used to sh syntax, like it should have a
digit or a `-' at the end.  &> is barely acceptable.  I think Brian threw
it in as an afterthought, but you'd have to ask him. 

>A lot of people are seeing bash as not only an alternative to ksh, but
>a way to get back to one true shell.

`One true shell' is desirable?  I thought one of the great features of Unix
was that you could replace any part you didn't like with your own code,
including your shell.  I'd like to see bash become the most widely-used
shell around, but because it offers a superior alternative, not because it
includes every feeping creature under the sun. 

>If David Korn had added csh-style
>history and editing syntax and curly braces to ksh, ksh would have
>taken over.  Instead, ksh was kept "pure", and potential users stayed
>away.

I think that AT&T's indecision regarding ksh (`put it in the Toolchest,
charge big bucks, update it irregularly') and the fact that csh comes for
free on the BSD tapes had much more to do with ksh not `taking over'.  The
fact that ksh will come standard in System V.4 could increase it's
popularity greatly.  (Of course, everything in the world will come on the
System V.4 source tapes, and that is *not* an improvement.)

BSD is quite popular (and rightly so), but csh is the only usable
interactive shell in the distribution.  Most BSD users have no other
alternative.  I think that if they had csh and ksh to choose from up front,
there would be a lot more ksh users, regardless of whether or not the
baroque csh history editing syntax existed.  Just as a point of curiousity,
what shell do you think Mike Karels uses? 

The editing (by this I mean line editing, which vanilla csh doesn't have)
and history that ksh offers are superior alternatives to those offered by
csh.  I guess Korn didn't want to take what he saw as a step backwards
(compared to the 4.1BSD csh with job control, since that's what Korn had
when he began implementing ksh).  Curly brace expansion is in bash and the
latest version of ksh, `ksh88b' (but undocumented).  I feel that the good
features of csh, like curly braces, should be included in bash, but not
everything.  Even Brian has said that he's surprised by the amount of use
the csh-style history is getting. 

>It seems to me that the introduction to bash ought to state what the
>goals are, and right now what I'm hearing is "bash is designed to be
>a better interactive shell, and it incorporates all of the features
>that the authors like.  It is not intended to be fully compatible with
>existing shells."

My understanding is that it is intended to be fully compatible with the
POSIX shell spec, which itself is not fully compatible with existing shells
(in fact, only ksh88b currently conforms to the full Posix shell
specification).  After that, features of ksh.  Everything I saw from the
FSF on bash before and after I became involved said the same thing: bash is
an implementation of the POSIX shell spec, which is based on the Bourne and
Korn shells.  I even read something by rms in a GNUs bulletin that said
bash could possibly appear as a replacement for `sh' in some subsequent
Berkeley distribution, after ksh features were added.  I've never seen csh
mentioned. 

Chet Ramey
-- 
Chet Ramey
Network Services Group				"Help! Help! I'm being
Case Western Reserve University			 repressed!"
chet@ins.CWRU.Edu