From: lwall@netlabs.com (Larry Wall)
Subject: Re: The Revenge of CSH
Organization: NetLabs, Inc.
Date: Thu, 31 Dec 1992 04:00:54 GMT

In article <Bzz748.GDK@csn.org> bazyar@teal.csn.org (Jawaid Bazyar) writes:
:   The reason for this reply is that I'm one of a number of folks working
: on a csh clone (called GSH, and for the GNO/ME system for the Apple IIgs).

Namespace Collision Alert!  There's a gsh program that comes with Perl
and is used by many system administrators to do "global" remote shell
operations.  You thus risk some confusion if you ever plan to port your
program to other Unix systems.

: We intend to fix most if not all of these problems as we implement csh
: from scratch on a 16-bit platform.  But I take offense to the manner in 
: which csh's bugs are listed, and then be stated "csh sucks, is 
: totally unworthy", basically.  
:   So, let the flamefest begin.

Just because the best defense is a good offense doesn't mean that
your offense is defensible.

: > From: Tom Christiansen <tchrist@convex.COM>
:  
: > 		   Csh Programming Considered Harmful
: > 
: > Resolved: The csh is a tool utterly inadequate for programming, and
: > its use for such purposes should be strictly banned.
: 
:    Oops.  I've used csh scripts before.  Shall I beg forgiveness?

That depends on whether you think it's forgivable to shoot yourself in
the foot continually.
 
: > I am continually shocked and dismayed to see people write test cases,
: > install scripts, and other random hackery using the csh.  
: 
:   I am continually shocked and dismayed to see people not have
: command line editing, arrow-key history, job control, or many
: of the other things that csh (tcsh) provides and /bin/sh does not.

The title of Tom's missive is "Csh PROGRAMMING Considered Harmful".
You're implicitly assuming that programming environments *ought* to be
confused with interactive environments.  I do not hold this truth to be
self-evident.

: > Lack of
: > proficiency in the Bourne shell has been known to cause errors in /etc/rc
: > and .cronrc files, which is a problem, because you *must* write these files
: > in that language.
: 
:   That would seem to be braindamage on the part of the kernel and cron,
: don't you think?

It would seem so, but I don't think it.  :-)

Historically, csh is the usurper.  And as a programming language it has done
a distinctly lousy job of usurping.

The fact is that the Bourne shell provides a more consistent, powerful,
portable and yet lightweight interface for C programs that want to
start shell scripts.  Any C library system() or popen() function that
is correctly implemented will call /bin/sh.  Anything else would induce
total pandemonium and would render many, many programs non-portable.

At the height of csh's popularity, The BSD folks goofed and implemented
rsh in terms of csh, and we've been paying the price ever since, over
and over.

Hey, I started out being a csh bigot too.  And I still use csh for my
interactive shell.  And I avoid sh programming as much as possible.
You probably don't realize how much I'll do to avoid sh programming...  :-)

: > FILE DESCRIPTORS
: > 
: > The most common problem encountered in csh programming is that
: > you can't do file-descriptor manipulation.  All you are able to 
: > do is redirect stdin, or stdout, or dup stderr into stdout. 
: > Bourne-compatible shells offer you an abundance of more exotic
: > possibilities.    
: 
:   Possibilities that could be added to csh, if anyone cared to.

Most people don't have the opportunity to fix csh.  Most of us who
have had the opportunity chose to decline it.

:   Trivially fixed, by making >& _only_ redirect stderr, and having
: the shell check appropriately for > and >& going to the same file.
: I envison, oh, 10 lines of code? 

With 10 lines of code, you've just busted nearly every csh script in
existence.  If you aspire to be a language designer, you'll have to do
better than that.

: > You want to know the status of C, well, that's easy: it's in $?, or
: > $status in csh.  But if you want it from A, you're out of luck -- if
: > you're in the csh, that is.  In the Bourne shell, you can get it, although
: > doing so is a bit tricky.  Here's something I had to do where I ran dd's
: 
:    "bit tricky" seems a lot like "totally unsuited to" a task, to me.

Now who's thinking in terms of black and white, hmm?

A good language design must do two things:  make common things easy,
and hard things possible.  Csh does some of the first, and precious
little of the second.  Hence most csh loyalists turn out to be pretty
green, while us oldsters tend to get a bit more cynical over time...

: >     device=/dev/rmt8
: >     dd_noise='^[0-9]+\+[0-9]+ records (in|out)$'
: >     exec 3>&1
: >     status=`((dd if=$device ibs=64k 2>&1 1>&3 3>&- 4>&-; echo $? >&4) |
: > 		egrep -v "$dd_noise" 1>&2 3>&- 4>&-) 4>&1`
: >     exit $status;
: 
:   Hmm.  Too bad that's unreadable! :)

Unreadable beats unwritable any day.

:   "on some systems" means that there's a bug in csh on some systems,
: not that csh is devil-spawn.

It's amazing the positive feedback loop that can arise when two hyperbolists
start conversing...

: > You can't do this in the csh.  It takes more verbiage.
: 
:   Excuse me?  "You can't do this" and "It takes more verbiage" means
: IT CAN BE DONE.  

The pronouns "this" and "it" obviously refer to two different antecedents,
though I suppose a good editor would have asked Tom to clarify it anyway
just for those people who willfully misread things.

:   According to you, there exists the possiblity that a lexer smart
: enough to deal with that statement exists, therefore csh is inherently
: flawed because it doesn't implement that lexer?

Csh is inherently flawed.  Your program may not be, but then, it appears
to implement a different language.  Hence, Tom's article wasn't about
your language.  Why then are you being so defensive?  :-)

: > RANDOM BUGS
: 
:   They're bugs, so they could be fixed.

Fine, fix 'em, if you've got a fixation on 'em.
 
: > SUMMARY
: > While some vendors have fixed some of the csh's bugs (the tcsh also does
: > much better here), many have added new ones.  Most of its problems can
: > never be solved because they're not actually bugs per se, but rather the
: > direct consequences of braindead design decisions.  It's inherently flawed.
: 
:   That's garbage.  You have shown no proof for that statement.  I'm
: supposed to read a bug list and then believe that all the bugs are
: caused because csh is "inherently flawed"?

It's not so much garbage as hyperbole.  Even Jesus used hyperbole
regularly.  You seem to like to use it upon occasion yourself:

    Garbage!  No proof!  All the bugs!

Personally, I would never, ever, use hyperbole, but I'll back your right to
use it 110%!!!

: > Do yourself a favor, and if you *have* to write a shell script, do it in the
: > Bourne shell.  It's on every UNIX system out there.  However, behavior
: > can vary.
:
:   Gee.. that means that /bin/sh isn't the universal be-all end-all of
: shells?  You don't say?  You mean /bin/sh has bugs?  Really?

The basic flaw of Bourne shell is not the presence of bugs, but the
absence of features.  Which means it depends heavily on the health of
every program it has intercourse with.  And most of those programs have
had a pretty sordid history.

Csh, being a shell, has some of these same personality problems:
Good for screwing around with and having fun, but watch out for those
second-hand bugs.  Me, I prefer monoprogrammy.

: >     Tom Christiansen      tchrist@convex.com      convex!tchrist
: > 
: >     "UNIX was not designed to stop you from doing stupid things, because
: >      that would also stop you from doing clever things." -- Doug Gwyn
: 
:    You're not cool enough to quote Doug Gwyn.

Oh, so it's a pissing contest now, is it?  How homo sapient of you.

Rool of Cool #1: If you really want people to think you're pretty slick,
		 just keep on fighting snot with snot...

Personally, I don't care whether someone is cool enough to quote Doug
Gwyn--I only care whether Doug Gwyn is cool enough to quote.

And you can quote me on that.

: Really; it seems that 'csh sucks' in your opinion because it's not /bin/sh.

Csh sucks because it's a lot of things--"not /bin/sh" is just one of them.

:    All in all, I'm sorely tempted to grab the existing csh source
: and fix it, but I'll continue on our from-scratch project and 
: do it that way.

Good decision.  Had you looked at the csh source, you would not only
have risked madness, but your mind would by now be a wholey-owned
subsidiary of, lesse, who is it these days, Novell, which is madness
enough.

:  --Apple II Forever!--

Figgers...

Love,
Larry Wall
lwall@netlabs.com

P.S. Usenet was not designed to stop you from saying stupid things, because
     that would also stop me from saying clever things.
Newsgroups: comp.unix.questions