The csh is seductive because the conditionals are more [C]-like, so the path of least resistance is chosen and a csh script is written. Sadly, this is a lost cause, and the programmer seldom even realizes it, even when they find that many simple things they wish to do range from cumbersome to impossible in the csh. 

  

 !!! 1. FILE DESCRIPTORS 

 !! 1a. Writing Files 

  

 In the BourneShell, you can open or dup arbitrary file descriptors. For example, 

  

  

 means that from then on, STDERR goes into errs file. 

  

 Or what if you just want to throw away STDERR and leave STDOUT alone? Pretty simple operation, eh? 

  

  

 Works in the BourneShell. In the csh, you can only make a pitiful attempt like this: 

  

  

 But who said that STDOUT was my tty? So it's wrong. This simple operation __''cannot be done''__ in the csh. 

  

 Along these same lines, you can't direct error messages in csh scripts out STDERR as is considered proper. In the BourneShell, you might say: 

  

  

 but in the csh, you can't redirect STDOUT out STDERR, so you end up doing something silly like this: 

  

  

 !! 1b. Reading Files 

  

 In the csh, all you've got is $<, which reads a line from your tty. What if you've redirected STDIN? Tough noogies, you still get your tty, which you really can't redirect. Now, the read statement in the BourneShell allows you to read from STDIN, which catches redirection. It also means that you can do things like this: 

  

  

 Now you can read from fd 3 and get lines from file1, or from file2 through fd 4. In modern, Bourne-like shells, this suffices: 

  

  

 Although in older ones where read only goes from 0, you trick it: 

  

  

 !! 1c. Closing FDs 

  

  

 !! 1d. More Elaborate Combinations 

  

 Maybe you want to pipe STDERR to a command and leave STDOUT alone. Not too hard an idea, right? You can't do this in the csh as I mentioned in 1a. In a BourneShell, you can do things like this: 

  

  

  

 Consider the pipeline: 

  

  

  

  

 The csh has also been known to close all open file descriptors besides the ones it knows about, making it unsuitable for applications that intend to inherit open file descriptors. 

  

 !!! 2. COMMAND ORTHOGONALITY 

 !! 2a. Built-ins 

  

 The csh is a horrid botch with its built-ins. You can't put them together in many reasonable ways. Even simple little things like this: 

  

  

 which while nonsensical, shouldn't give me this message: 

  

  

 Others are more fun: 

  

  

 Some can even hang your shell. Try typing ^Z while you're sourcing something, or redirecting a source command. Just make sure you have another window handy. Or try 

  

  

 on some systems. 

  

 Aliases are not evaluated everywhere you would like them do be: 

  

  

  

 !! 2b. Flow control 

  

 You can't mix flow-control and commands, like this: 

  

  

 You can't combine multiline constructs in a csh using semicolons. There's no easy way to do this 

  

  

 (See [Foo] and [Bar].) 

  

 You can't perform redirections with if statements that are evaluated solely for their exit status: 

  

  

 And even pipes don't work: 

  

  

 But these work just fine in the BourneShell: 

  

  

  

 Consider the following reasonable construct: 

  

  

 The output of command1 won't go into the input of command2. You will get the output of both commands on standard output. No error is raised. In the BourneShell or its clones, you would say 

  

  

 !! 2c. Stupid parsing bugs 

  

 Certain reasonable things just don't work, like this: 

  

  

 But this is ok: 

  

  

 If you have a stopped job: 

  

  

 You should be able to kill it with 

  

  

 but 

  

  

 works. 

  

 White space can matter: 

  

  

 may fail on some versions of csh, while 

  

  

 works! Your vendor may have attempted to fix this bug, but odds are good that their csh still won't be able to handle 

  

  

 !!! 3. SIGNALS 

  

 In the csh, all you can do with signals is trap SIGINT. In the BourneShell, you can trap any signal, or the end-of-program exit. For example, to blow away a tempfile on any of a variety of signals: 

  

  

  

 !!! 4. QUOTING 

  

 You can't quote things reasonably in the csh: 

  

  

 doesn't work. This makes it really hard to construct strings with mixed quotes in them. In the BourneShell, this works just fine. In fact, so does this: 

  

  

 Dollar signs cannot be escaped in double quotes in the csh. Ug. 

  

  

 You have to use backslashes for newlines, and it's just darn hard to get them into strings sometimes. 

  

  

 Say what? You don't have these problems in the BourneShell, where it's just fine to write things like this: 

  

  

 As distributed, quoting history references is a challenge. Consider: 

  

  

 !!! 5. VARIABLE SYNTAX 

  

 There's this big difference between global (environment) and local (shell) variables. In csh, you use a totally different syntax to set one from the other. 

  

 In the BourneShell, this 

 is the same as 

 or csh's 

  

 You can't use :t, :h, etc on envariables. Watch: 

  

 It's really nice to be able to say 

  

 or 

  

 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. 

  

 You can't get the process number of the last background command from the csh, something you might like to do if you're starting up several jobs in the background. In the BourneShell, the pid of the last command put in the background is available in $!. 

  

 The csh is also flaky about what it does when it imports an environment variable into a local shell variable, as it does with HOME, USER, PATH, and TERM. Consider this: 

  

  

 And watch the fun! 

  

 !!! 6. EXPRESSION EVALUATION 

  

 Consider this statement in the csh: 

  

  

 Despite your attempts to only set PAGER when you want to, the csh aborts: 

  

  

 That's because it parses the whole line anyway __and evaluates it__! You have to write this: 

  

  

 That's the same problem you have here: 

  

  

 This forces you to write a couple nested if statements. This is highly undesirable because it renders short-circuit booleans useless in situations like these. If the csh were the really [C]-like, you would expect to be able to safely employ this kind of logic. Consider the common [C] construct: 

  

  

 Undefined variables are not fatal errors in the BourneShell, so this issue does not arise there. 

  

 While the csh does have built-in expression handling, it's not what you might think. In fact, it's space sensitive. This is an error 

  

  

 but this is ok 

  

  

 The ad hoc parsing csh employs fouls you up in other places as well. Consider: 

  

  

 !!! 7. ERROR HANDLING 

  

 Wouldn't it be nice to know you had an error in your script before you ran it? That's what the -n flag is for: just check the syntax. This is especially good to make sure seldom taken segments of code code are correct. Alas, the csh implementation of this doesn't work. Consider this statement: 

  

  

 Of course, they really meant 

  

  

 or just 

  

  

 Either shell will complain about this. But if you hide this in an if clause, like so: 

  

  

 The csh tells you there's nothing wrong with this script. The equivalent construct in the BourneShell, on the other hand, tells you this: 

  

  

  

 !! RANDOM BUGS 

  

 Here's one: 

  

  

 Huh? Here's another 

  

  

 Coredump, or garbage. 

  

 If you have an alias with backquotes, and use that in backquotes in another one, you get a coredump. 

  

 Try this: 

 What??? 

  

 Here's another one: 

  

 !!! 8. SUMMARY 

  

 While some vendors have fixed some of the csh's bugs (the tcsh(1) 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. 

  

  

 There are other possibilities. 

  

 The Korn shell is the preferred programming shell by many sh addicts, but it still suffers from inherent problems in the BourneShell's design, such as parsing and evaluation horrors. The Korn shell or its public-domain clones and supersets (like bash) aren't quite so ubiquitous as sh, so it probably wouldn't be wise to write a sharchive in them that you post to the net. When 1003.2 becomes a real standard that companies are forced to adhere to, then we'll be in much better shape. Until then, we'll be stuck with bug-incompatible versions of the sh lying about. 

  

 The Plan 9 shell, rc, is much cleaner in its parsing and evaluation; it is not widely available, so you'd be significantly sacrificing portability. No vendor is shipping it yet.