From: chet@odin.ins.cwru.edu (Chet Ramey)
Newsgroups: comp.unix.questions
Subject: Re: The Revenge of CSH
Date: 29 Dec 92 16:01:04 GMT
Organization: Case Western Reserve University, Cleveland OH (USA)
NNTP-Posting-Host: odin.ins.cwru.edu

In article <Bzz748.GDK@csn.org> bazyar@teal.csn.org (Jawaid Bazyar) writes:

>  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.

As others have stated, these are all interactive features, not the
script features about which Tom is complaining.

>  Possibilities that could be added to csh, if anyone cared to.

...and once they were, until they were standard and ubiquitous, they
would be useless.  Ditto for `read', `fixing' redirections, `fixing'
piping to and from csh builtins, the equivalent to $!, `fixing' the
lexical analyzer, and other things mentioned.

[...]
>  Hmm.  Too bad that's unreadable! :)

``The easy things should be easy; the hard things should be possible.''
At least this stuff is possible in sh.  The csh model is too confining.
I think this is the crux of Tom's argument.

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

`On some systems' means, in this case, every job-control capable Unix
system with csh, since few vendors have fixed these things.  They are
part of what you have to consider when dealing with csh.

>  ^^^^  He devotes a whole section to implementation errors.  These
>are _bugs_, i.e. they could be fixed or avoided in a new implementation
>(like GSH).

...and until the `new' implementation is standard and ubiquitous, it's
useless when considering `portable' csh scripts.  Same thing with sh
and shell functions, since BSD and Ultrix shells don't support them
yet. (Well, the BSD sh as of 4.3-net2 does, but it has its own set of
problems).  Larry Wall, who wrote more twisted sh code than anyone
(before perl, that is :-), says he's never written a shell function for
just this reason.

>  Too bad the Bourne shell doesn't support real BSD job control.

This is a result of, for the most part, the fact that AT&T kernels did
not support job control, and there was therefore no reason to add it to
sh.  The sh shipped with V.4 supports Posix job control, now that the
proper kernel support is there.  The new BSD sh supports job control.
(Hey, bash supports job control :-).

The csh doesn't give you job control in scripts, anyway.  We're talking
about shell programming here.

>> You can't quote things reasonably in the csh:
> 
>>     set foo = "Bill asked, \"How's tricks?\""
> 
>> doesn't work.  This makes it really hard to construct strings with
>> mixed quotes in them.  In the Bourne shell, this works just fine. 
>> In fact, so does this:
>> 
>>      cd /mnt; /usr/ucb/finger -m -s `ls \`u\``
>> 
>> Dollar signs cannot be escaped in double quotes in the csh.  Ug.
>> 
>>     set foo = "this is a \$dollar quoted and this is $HOME not quoted" 
>>     dollar: Undefined variable.
>
>  Another bug.

Which?  The `dollar signs cannot be escaped in double quotes' problem, or
the hoops one must jump through to quote things reasonably?  It seems to me
that the entire csh quoting model is flawed because it is not sufficiently
flexible.  Perhaps you consider this an implementation problem. 

>> Say what?  You don't have these problems in the Bourne shell, where it's
>> just fine to write things like this:
>>     echo 	'This is 
>> 	     some text that contains
>> 	     several newlines.'
> 
>  So what?

You don't consider this useful?  Or do you consider it trivial?

>> It's really nice to be able to say
>>     
>>     ${PAGER-more}
>> or
>>     FOO=${BAR:-${BAZ}}
>> 
>> to be able to run the user's PAGER if set, and more otherwise.
>> 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 sh syntax is more compact and powerful.  It takes a number of csh
if statements to perform the same task.  You cannot do it in a single
statement the way sh can.  I believe that this was Tom's point.

>   You're not cool enough to quote Doug Gwyn.  Really; it seems that
>'csh sucks' in your opinion because it's not /bin/sh.  Care to try 
>again?

Oh, I don't know.  Tom's a pretty cool guy.  I prefer to quote Chris
Torek, myself:

``The C shell is an object lesson in how not to write programs.''

Chet
-- 
``The use of history as therapy means the corruption of history as history.''
	-- Arthur Schlesinger

Chet Ramey, Case Western Reserve University	Internet: chet@po.CWRU.Edu