Editing C shell (section)

== Reception ==
Although [[Stephen R. Bourne|Stephen Bourne]] himself acknowledged that csh was superior to his shell for interactive use,<ref name="bourne198310">{{cite news | url=https://archive.org/stream/byte-magazine-1983-10/1983_10_BYTE_08-10_UNIX#page/n187/mode/2up | title=The Unix Shell | work=BYTE | date=October 1983 | access-date=30 January 2015 | author=Bourne, Stephen R. | pages=187}}</ref> it has never been as popular for scripting.

In 1983, both csh and Bourne shell were available for Charles River Data Systems' [[UNOS (operating system)|UNOS]] operating system among other UNIX tools under [[Bell Laboratories]] license.<ref>{{Cite book|year=1983|title=The Insider's Guide To The Universe|publisher=Charles River Data Systems, Inc.|url=https://www.1000bit.it/ad/bro/charles/CharlesRiverSystem-Universe.pdf|page=13}}</ref>

Initially, and through the 1980s, csh could not be guaranteed to be present on all Unix and Unix-like 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,<ref>''IEEE Standard for Information Technology, Portable Operating System Interface (POSIX), Part 2:  Shell and Utilities, Volume 2''.  IEEE Std 1003.2-1992, pp. 766-767.  {{ISBN|1-55937-255-9}}.</ref> which specified that there should only be one preferred shell, the [[KornShell]], for both interactive and scripting purposes.  The C shell also faced criticism from others<ref>[http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/ ''Csh Programming Considered Harmful''] by Tom Christiansen</ref><ref>[http://www.grymoire.com/Unix/CshTop10.txt ''Top Ten Reasons not to use the C shell''] by Bruce Barnett</ref> 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 <code>set</code>, <code>setenv</code> and <code>alias</code> 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 <code>set</code> but not for <code>setenv</code> or <code>alias</code>; parentheses were required around a word list for a <code>set</code> but not for <code>setenv</code> or <code>alias</code>, etc.  Similarly, the <code>if</code>, <code>switch</code> and looping constructs use needlessly different keywords (<code>endif</code>, <code>endsw</code> and <code>end</code>) 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. Although lacking support for functions, aliases serve as workaround. For multiple lines of code, aliases must be within single quotes, and each end of line must precede a backslash (the end of the last line must precede a single quote to delimit the end of the alias). Recursion is favorable over aliases in scripts as workaround for functions (an example is given below).
* The implementation: which used an ad hoc [[parsing|parser]], has drawn the most serious criticism.  By the early 1970s, [[compiler]] technology was sufficiently mature<ref>David Gries (1971).  ''Compiler Construction for Digital Computers.'' John Wiley & Sons. {{ISBN|0-471-32776-X}}.</ref> that most new language implementations used either a [[top-down parsing|top-down]] or [[bottom-up parsing|bottom-up parser]] capable of recognizing a fully recursive [[Formal grammar|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."<ref>{{usurped|1=[https://web.archive.org/web/20100330044908/http://fora.tv/2009/02/11/Bill_Joy_in_Conversation_with_Brent_Schlender Bill Joy in Conversation with Brent Schlender, Churchill Club, Santa Clara, CA, 11 Feb 2009]}}.</ref> 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 <code>foreach</code> command into <code>[[grep]]</code> 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 <code>foreach</code> 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. It's also possible to break codes in a single file. An example is given below on how to break codes in a single file.)

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.

{{column|num=4
|width=90em
|1=
<syntaxhighlight lang="bash">
# Works as expected
if ( ! -e myfile ) then
   echo mytext > myfile
endif
</syntaxhighlight>
|2=
<syntaxhighlight lang="csh">
# Always creates an empty file
if (! -e myfile) echo mytext > myfile
</syntaxhighlight>
|3=
<syntaxhighlight lang="csh">
# Workaround (only for tcsh)
if (! -e myfile) eval "echo mytext > myfile"
</syntaxhighlight>
<syntaxhighlight lang="csh">
# Second workaround (for csh and tcsh)
( exit ( -e myfile ) && ( ( echo mytext > myfile ) >& /dev/null || echo Cannot create file. ) || echo File exists.
</syntaxhighlight>
}}

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.

However, by practicing, it's possible to overcome those deficiencies (thus instructing the programmer to take better and safer approaches on implementing a script).

The "0: Event not found." error implies there aren't saved commands in the history. The history may not work properly in scripts, but having a pre-set of commands in a variable serves as workaround.

<syntaxhighlight lang="csh">
#!/bin/csh -f
set cmdlist = ( 'date # 1'\
'uname # 2'\
'tty # 3'\
'id # 4' )
echo -n 'Enter a number to execute a command from the history: '
set cmdexec = "$<"
( exit ( ! ( "$cmdexec" > 0 && \
"$cmdexec" <= "$#cmdlist" ) ) ) >& /dev/null
if ( "$status" ) then
  echo 'Invalid event number.'
  foreach cmd ( $cmdlist:q )
    echo "$cmd"
  end
  exit -1
endif
eval "$cmdlist[$cmdexec]"
</syntaxhighlight>

Prefer breaking codes by recursing the script as workaround for functions.

<syntaxhighlight lang="csh">
#!/bin/csh -f
if ( ! "$?main" ) then
  if ( ! "$?0" ) then
    echo 'You must run this script by explicitly calling its file.'
    exit -1
  endif
  alias function 'set argv = ( \!* ) ; source "$main"'
  set main = "$0"
  set ret = "`function myfunc`"
  echo "$ret"
  exit
endif

goto "$1" ; shift

myfunc:
function myfunc2
echo "A function."
exit

myfunc2:
echo "Another function."
exit
</syntaxhighlight>