C Shell - Criticism

Criticism

Though popular for interactive use because of its many innovative features, csh has never been as popular for scripting. Initially, and through the 1980s, csh could not be guaranteed to be present on all Unix systems, but sh could, which made it a better choice for any scripts that might have to run on other machines. By the mid-1990s, csh was widely available, but the use of csh for scripting faced new criticism by the POSIX committee, which specified that there should only be one preferred shell, the Korn Shell, for both interactive and scripting purposes. The C shell also faced criticism from others over the C shell's alleged defects in syntax, missing features, and poor implementation.

Syntax defects were generally simple but unnecessary inconsistencies in the definition of the language. For example, the set, setenv and alias commands all did basically the same thing, namely, associate a name with a string or set of words. But all three had slight but unnecessary differences. An equal sign was required for a set but not for setenv or alias; parentheses were required around a word list for a set but not for setenv or alias, etc. Similarly, the if, switch and looping constructs use needlessly different keywords (endif, endsw and end) to terminate the nested blocks.

Missing features most commonly cited are the lack of ability to manipulate the stdio file handles independently and support for functions. Whereas Bourne shell functions lacked only local variables, Csh's aliases - the closest analogue in Csh to functions - were restricted to single lines of code, even though most flow control constructs required newlines to be recognized. As a result, Csh scripts could not be functionally broken down as C programs themselves could be, and larger projects tended to shift to either Bourne shell scripting or C code.

The implementation, which used an ad hoc parser, has drawn the most serious criticism. By the early 1970s, compiler technology was sufficiently mature that most new language implementations used either a top-down or bottom-up parser capable of recognizing a fully recursive grammar. It is not known why an ad hoc design was chosen instead for the C shell. It may be simply that, as Joy put it in an interview in 2009, "When I started doing this stuff with Unix, I wasn't a very good programmer." The ad hoc design meant that the C shell language was not fully recursive. There was a limit to how complex a command it could handle.

It worked for most interactively typed commands, but for the more complex commands a user might write in a script, it could easily fail, producing only a cryptic error message or an unwelcome result. For example, the C shell could not support piping between control structures. Attempting to pipe the output of a foreach command into grep simply didn't work. (The work-around, which works for many of the complaints related to the parser, is to break the code up into separate scripts. If the foreach is moved to a separate script, piping works because scripts are run by forking a new copy of csh that does inherit the correct stdio handles.)

Another example is the unwelcome behavior in the following fragments. Both of these appear to mean, "If 'myfile' does not exist, create it by writing 'mytext' into it." But the version on the right always creates an empty file because the C shell's order of evaluation is to look for and evaluate I/O redirection operators on each command line as it reads it, before examining the rest of the line to see whether it contains a control structure.

The implementation is also criticized for its notoriously poor error messages, e.g., "0 event not found", which yields no useful information about the problem.