Editing C shell

{{short description|Unix shell}}
{{Use dmy dates|date=December 2020}}
{{Infobox software
| name                    = C shell
| logo                    =
| screenshot              = Tcsh ejecutándose en escritorio Mac OSX.png
| caption                 = tcsh and sh side-by-side on a Mac OS X desktop
| author                  = [[Bill Joy]]
| developer               =
| released                = {{start date and age|1978}}
| discontinued            =
| latest_release_version = 6.20.00
| latest_release_date = {{Start date and age|df=yes|2016|11|24}}<ref>{{Citation
 |mode         = cs1
 |last         = Zoulas
 |first        = Christos
 |title        = tcsh-6.20.00 is now available!
 |date         = 24 November 2016
 |url          = http://mx.gw.com/pipermail/tcsh/2016-November/005021.html
 |website      = mx.gw.com
 |access-date   = 24 November 2016
 |archive-url  = https://web.archive.org/web/20161125044614/http://mx.gw.com/pipermail/tcsh/2016-November/005021.html
 |archive-date = 25 November 2016
 |url-status=dead}}</ref>
| programming language    = [[C (programming language)|C]]
| operating system        = [[Berkeley Software Distribution|BSD]], [[UNIX]], [[UNOS (operating system)|UNOS]], [[Linux]], [[macOS]]
| genre                   = [[Unix shell]]
| license                 = [[BSD license]]
}}
[[File:C Shell running on SUA.png|thumb|C Shell running on [[Windows Services for UNIX]]]]
The '''C shell''' ('''csh''' or the improved version, '''[[tcsh]]''') is a [[Unix shell]] created by [[Bill Joy]] while he was a graduate student at [[University of California, Berkeley]] in the late 1970s. It has been widely distributed, beginning with the 2BSD release of the [[Berkeley Software Distribution]] (BSD) which Joy first distributed in 1978.<ref>Harley Hahn, [http://unix.harley.com/instructors/timeline.html Harley Hahn's Guide to Unix and Linux] {{Webarchive|url=https://web.archive.org/web/20190824231900/http://unix.harley.com/instructors/timeline.html |date=24 August 2019 }}.</ref><ref>[http://coe.berkeley.edu/labnotes/history_unix.html Berkeley Engineering Lab Notes, Volume 1, Issue 2, October 2001] {{Webarchive|url=https://web.archive.org/web/20100709223314/http://coe.berkeley.edu/labnotes/history_unix.html |date=9 July 2010 }}.</ref> Other early contributors to the ideas or the code were Michael Ubell, [[Eric Allman]], Mike O'Brien and Jim Kulp.<ref>[http://www.kitebird.com/csh-tcsh-book/csh-intro.pdf ''An Introduction to the C shell''] {{Webarchive|url=https://web.archive.org/web/20180713012111/http://www.kitebird.com/csh-tcsh-book/csh-intro.pdf |date=13 July 2018 }} by [[Bill Joy]].</ref>

The C shell is a [[Command-line interpreter|command processor]] which is typically run in a text window, allowing the user to type and execute commands. The C shell can also read commands from a file, called a [[Shell script|script]].  Like all Unix shells, it supports filename [[Wildcard character|wildcarding]], [[Pipeline (Unix)|piping]], [[here document]]s, [[command substitution]], [[Variable (programming)|variables]] and [[control flow|control structures]] for [[Conditional (programming)|condition-testing]] and [[iteration]].  What differentiated the C shell from others, especially in the 1980s, were its interactive features and overall style.  Its new features made it easier and faster to use.  The overall style of the language looked more like [[C (programming language)|C]] and was seen as more readable.

On many systems, such as [[macOS]] and [[Red Hat Linux]], csh is actually [[tcsh]], an improved version of csh.  Often one of the two files is either a [[hard link]] or a [[symbolic link]] to the other, so that either name refers to the same improved version of the C shell. The original csh source code and binary are part of [[NetBSD]].

On [[Debian]] and some derivatives (including [[Ubuntu (operating system)|Ubuntu]]), there are two different packages: csh and tcsh. The former is based on the original BSD version of csh<ref>[https://launchpad.net/ubuntu/+source/csh Ubuntu - Details of package csh]. launchpad.net.</ref><ref>[https://tracker.debian.org/pkg/csh Debian - Details of package csh]. tracker.debian.org.</ref> and the latter is the improved tcsh.<ref>[https://launchpad.net/ubuntu/+source/tcsh Ubuntu - Details of package tcsh]. launchpad.net.</ref><ref>[https://tracker.debian.org/pkg/tcsh Debian - Details of package tcsh]. tracker.debian.org.</ref>

tcsh added filename and command completion and command line editing concepts borrowed from the [[TOPS-20#TENEX|Tenex]] system, which is the source of the "t".<ref name=Greer>
{{Cite newsgroup
| author     = Ken Greer
| title      = C shell with command and filename recognition/completion
| date       = 3 October 1983
| newsgroup  = net.sources
| url        = https://groups.google.com/group/net.sources/msg/7073bf41cc5da330?hl=en
| access-date = 29 December 2010
}}</ref> Because it only added functionality and did not change what already existed, tcsh remained [[backward compatible]]<ref>[https://web.archive.org/web/20060117151444/http://www.tcsh.org/tcsh.html/DESCRIPTION.html tcsh(1) man page]. tcsh.</ref> with the original C shell.  Though it started as a side branch from the original source tree Joy had created, tcsh is now the main branch for ongoing development.  tcsh is very stable but new releases continue to appear roughly once a year, consisting mostly of minor bug fixes.<ref>Fixes file in tcsh-17 June 2000.</ref>

== Design objectives and features ==

The main design objectives for the C shell were that it should look more like the [[C (programming language)|C programming language]] and that it should be better for interactive use.

=== More like C ===

The Unix system had been written almost exclusively in C, so the C shell's first objective was a command language that was more stylistically consistent with the rest of the system.  The keywords, the use of parentheses, and the C shell's built-in expression grammar and support for arrays were all strongly influenced by C.

By today's standards, C shell may not seem particularly more C-like than many other popular scripting languages.  But through the 1980s and '90s, the difference was seen as striking, particularly when compared to [[Bourne shell]] (also known as ''sh''), the then-dominant shell written by [[Stephen R. Bourne|Stephen Bourne]] at [[Bell Labs]].  This example illustrates the C shell's more conventional [[Operator (computer programming)|expression operators]] and [[Syntax (programming languages)|syntax]].

{{column
|width=60em
|1=
Bourne shell
<syntaxhighlight lang="bash">
#!/bin/sh
if [ $days -gt 365 ]
then
   echo This is over a year.
fi
</syntaxhighlight>
|2=
C shell
<syntaxhighlight lang="csh">
#!/bin/csh
if ( $days > 365 ) then
   echo This is over a year.
endif
</syntaxhighlight>
}}

The Bourne sh lacked an [[Expression (programming)|expression grammar]]. The square bracketed condition had to be evaluated by the slower means of running the external [[test (Unix)|test]] program.  sh's <code>if</code> command took its argument words as a new command to be run as a [[Process (computing)|child process]].  If the child exited with a zero [[return code]], sh would look for a <code>then</code> clause (a separate statement, but often written joined on the same line with a semicolon) and run that nested block.  Otherwise, it would run the else. [[Hard link|Hard-linking]] the test program as both "<code>test</code>" and "<code>[</code>" gave the notational advantage of the square brackets and the appearance that the functionality of test was part of the sh language.  sh's use of a reversed keyword to mark the end of a control block was a style borrowed from [[ALGOL 68]].<ref>[https://groups.google.com/group/comp.lang.misc/msg/d58db4799c33e093?hl=en&dmode=source ''Re: Late Bloomers Revisited''] USENET post to comp.lang.misc by Piercarlo "Peter" Grandi, Dept of CS, UCW Aberystwyth, UK, 17 December 1989.</ref>

By contrast, csh could evaluate the expression directly, which made it faster.  It also claimed better readability:  Its expressions used a [[Formal grammar|grammar]] and a set of operators mostly copied from C, none of its keywords were reversed and the overall style was also more like C.

Here is a second example, comparing scripts that calculate the first 10 powers of 2.

{{column
|width=60em
|1=
Bourne shell
<syntaxhighlight lang="bash">
#!/bin/sh
i=2
j=1
while [ $j -le 10 ]
do
   echo '2 **' $j = $i
   i=`expr $i '*' 2`
   j=`expr $j + 1`
done
</syntaxhighlight>
|2=
C shell
<syntaxhighlight lang="csh">
#!/bin/csh
set i = 2
set j = 1
while ( $j <= 10 )
   echo '2 **' $j = $i
   @ i *= 2
   @ j++
end
</syntaxhighlight>
}}

Again because of the lack of an expression grammar, the sh script uses [[command substitution]] and the [[expr]] command. (Modern [[POSIX shell]] ''does'' have such a grammar: the statement could be written {{code|1=i=$((i * 2))}} or {{code|1=: "$((i *= 2))"}}.)

Finally, here is a third example, showing the differing styles for a [[switch statement]].

{{column
|width=60em
|1=
Bourne shell
<syntaxhighlight lang="bash">
#!/bin/sh
for i in d*
do
   case $i in
      d?) echo $i is short ;;
      *) echo $i is long ;;
   esac
done
</syntaxhighlight>
|2=
C shell
<syntaxhighlight lang="csh">
#!/bin/csh
foreach i ( d* )
   switch ( $i )
      case d?:
         echo $i is short
         breaksw
      default:
         echo $i is long
   endsw
end
</syntaxhighlight>
}}

In the sh script, "<code>;;</code>" marks the end of each case because sh disallows null statements otherwise.

=== Improvements for interactive use ===

The second objective was that the C shell should be better for interactive use.  It introduced numerous new features that made it easier, faster and more [[User-friendly|friendly]] to use by typing commands at a terminal.  Users could get things done with a lot fewer keystrokes and it ran faster.  The most significant of these new features were the history and editing mechanisms, aliases, directory stacks, tilde notation, cdpath, job control, and path hashing.  These new features proved very popular, and many of them have since been copied by other Unix shells.

==== History ====

History allows users to recall previous commands and rerun them by typing only a few quick keystrokes. For example, typing two exclamation marks ("<code>!!</code>")<ref>Pronounced ''"bang, bang"''</ref> as a command causes the immediately preceding command to be run. Other short keystroke combinations, e.g., "<code>!$</code>" (meaning "the final argument of the previous command"), allow bits and pieces of previous commands to be pasted together and edited to form a new command.

==== Editing operators ====

Editing can be done not only on the text of a previous command, but also on variable substitutions.  Operators range from simple string search/replace to parsing a pathname to extract a specific segment.

====Aliases====

Aliases allow the user to type the name of an alias and have the C shell expand it internally into whatever set of words the user has defined.  For many simple situations, aliases run faster and are more convenient than scripts.

==== Directory stack ====

The directory [[Stack (data structure)|stack]] allows the user to [[pushd and popd|push or pop]] the [[current working directory]], making it easier to jump back and forth between different places in the filesystem.

==== Tilde notation ====

Tilde notation offers a shorthand way of specifying pathnames relative to the [[home directory]] using the "<code>~</code>" character.

==== Filename completion ====

The [[esc key|escape key]] can be used interactively to show possible completions of a filename at the end of the current command line.

==== Cdpath ====

Cdpath extends the notion of a [[PATH (variable)|search path]] to the <code>cd</code> (change directory) command:  If the specified directory is not in the [[current directory]], csh will try to find it in the cdpath directories.

==== Job control ====

Well into the 1980s, most users only had simple character-mode terminals that precluded multiple windows, so they could only work on one task at a time. The C shell's job control allowed the user to suspend the current activity and create a new instance of the C shell, called a job, by typing <code>[[Control-Z|^Z]]</code>. The user could then switch back and forth between jobs using the <kbd>fg</kbd> command.  The active job was said to be in the foreground.  Other jobs were said to be either suspended (stopped) or running in the [[Background process|background]].

==== Path hashing ====

Path hashing speeds up the C shell's search for executable files.  Rather than performing a filesystem call in each path directory, one at a time, until it either finds the file or runs out of possibilities, the C shell consults an internal [[hash table]] built by scanning the path directories.  That table can usually tell the C shell where to find the file (if it exists) without having to search and can be refreshed with the <code>rehash</code> command.

== Overview of the language ==

The C shell operates one line at a time.  Each line is [[Lexical analysis|tokenized]] into a set of words separated by spaces or other characters with special meaning, including parentheses, piping and input/output redirection operators, semicolons, and ampersands.

=== Basic statements ===

A basic statement is one that simply runs a command.  The first word is taken as name of the command to be run and may be either an internal command, e.g., <code>echo</code>, or an external command.  The rest of the words are passed as arguments to the command.

At the basic statement level, here are some of the features of the grammar:

==== Wildcarding ====

The C shell, like all Unix shells, treats any command-line argument that contains wildcard characters as a pattern and replaces it with the list of all the filenames that match (see [[globbing]]).

*<code>*</code> matches any number of characters.
*<code>?</code> matches any single character.
*<code>[</code>...<code>]</code> matches any of the characters inside the square brackets.  Ranges are allowed, using the hyphen.
*<code>[^</code>...<code>]</code> matches any character ''not'' in the set.

The C shell also introduced several notational conveniences (sometimes known as [[extended globbing]]), since copied by other Unix shells.

*<code>abc{def,ghi}</code> is [[Alternation (string expansion)|alternation]] (aka [[Bash (Unix shell)#Brace expansion|brace expansion]]) and expands to ''abcdef'' ''abcghi''.
*<code>~</code> means the current user's home directory.
*<code>~user</code> means ''user'''s home directory.

Multiple directory-level wildcards, e.g., "<code>*/*.c</code>", are supported.

Since version 6.17.01, recursive wildcarding à la [[Z shell|zsh]] (e.g. "<code>**/*.c</code>" or "<code>***/*.html</code>") is also supported with the <code>globstar</code> option.

Giving the shell the responsibility for interpreting wildcards was an important decision on Unix.  It meant that wildcards would work with every command, and always in the same way.  However, the decision relied on Unix's ability to pass long argument lists efficiently through the [[exec (system call)|exec]] system call that csh uses to execute commands.  By contrast, on [[Windows]], wildcard interpretation is conventionally performed by each application. This is a legacy of MS-DOS, which only allowed a 128-byte command line to be passed to an application, making wildcarding by the DOS command prompt impractical. Although modern [[Microsoft Windows|Windows]] can pass command lines of up to roughly 32K [[Unicode]] characters, the burden for wildcard interpretation remains with the application.

==== I/O redirection ====

By default, when csh runs a command, the command inherits the csh's stdio file handles for [[stdin]], [[stdout]] and [[stderr]], which normally all point to the [[console window]] where the C shell is running.  The i/o redirection operators allow the command to use a file instead for input or output.

*<code>> <em>file</em></code> means stdout will be written to ''file'', overwriting it if it exists, and creating it if it doesn't.  Errors still come to the shell window.
*<code>>& <em>file</em></code> means both stdout and stderr will be written to ''file'', overwriting it if it exists, and creating it if it doesn't.
*<code>>> <em>file</em></code> means stdout will be appended at the end of ''file''.
*<code>>>& <em>file</em></code> means both stdout and stderr will be appended at the end of ''file''.
*<code>< <em>file</em></code> means stdin will be read from ''file''.
*<code><< <em>string</em></code> is a [[here document]].  Stdin will read the following lines up to the one that matches ''string''.

Redirecting stderr alone isn't possible without the aid of a sub-shell.

<syntaxhighlight lang="csh">
set filter = "$home"'/filter'
mkfifo "$filter"
cat "$filter" & ( ( ls /root/ || echo No access. ) > "$filter" ) >& /dev/null
</syntaxhighlight>

Systems supporting file descriptors as files may use the following workaround.

<syntaxhighlight lang="csh">
( ( ( echo ok ; '' ) > /dev/fd/0 ) >& /dev/null < /dev/fd/1 ) | ( echo "$<" bye )
</syntaxhighlight>

==== Joining ====

Commands can be joined on the same line.

*<code>;</code> means run the first command and then the next.
*<code>&&</code> means run the first command and, if it succeeds with a 0 [[return code]], run the next.
*<code>||</code> means run the first command and, if it fails with a non-zero return code, run the next.

==== Piping ====

Commands can be connected using a pipe, which causes the output of one command to be fed into the input of the next.  Both commands run [[Concurrency (computer science)|concurrently]].

*<code>|</code> means connect stdout to stdin of the next command.  Errors still come to the shell window.
*<code>|&</code> means connect both stdout and stderr to stdin of the next command.

Running concurrently means "in parallel".  In a [[Multi-core processor|multi-core]] (multiple processor) system, the piped commands may literally be executing at the same time, otherwise the [[Scheduling (computing)|scheduler]] in the operating system [[Time slice|time-slices]] between them.

Given a command, e.g., "<code>a | b</code>", the shell creates a [[pipeline (computing)|pipe]], then starts both <code>a</code> and <code>b</code> with stdio for the two commands redirected so that <code>a</code> writes its stdout into the input of the pipe while <code>b</code> reads stdin from the output of the pipe.  Pipes are implemented by the operating system with a certain amount of buffering so that <code>a</code> can write for a while before the pipe fills but once the pipe fills any new write will block inside the OS until <code>b</code> reads enough to unblock new writes.  If <code>b</code> tries to read more data than is available, it will block until <code>a</code> has written more data or until the pipe closes, e.g., if <code>a</code> exits.

==== Variable substitution ====

If a word contains a dollar sign, "<code>$</code>", the following characters are taken as the name of a variable and the reference is replaced by the value of that variable.  Various editing operators, typed as suffixes to the reference, allow pathname editing (e.g., "<code>:e</code>" to extract just the extension) and other operations.

==== Quoting and escaping ====

Quoting mechanisms allow otherwise special characters, such as whitespace, wildcards, parentheses, and dollar signs, to be taken as [[Literal (computer science)|literal]] text.

*<code>\</code> means take the next character as an ordinary literal character.
*<code>"</code>''string''<code>"</code> is a weak quote.  Enclosed whitespace and wildcards are taken as literals, but variable and command substitutions are still performed.
*<code>'</code>''string''<code>'</code> is a strong quote.  The entire enclosed string is taken as a literal.

Double quotes inside double quotes should be escaped with <code>"\""</code>. The same applies to the dollar symbol, to prevent variable expansion <code>"\$"</code>. For backticks, to prevent command substitution nesting, single quotes are required <code>"'\`'"</code>.

==== Command substitution ====

Command substitution allows the output of one command to be used as arguments to another.

*<code>`</code>''command''<code>`</code> means take the output of ''command'', parse it into words and paste them back into the command line.

The following is an example of nested command substitutions with [[Leaning toothpick syndrome]]:

<syntaxhighlight lang="csh">
echo "`echo "\"\`"echo "\"\\\"\\\`\""echo "\"\\\"\\\\\\\"\\\\\\\`\\\"\""echo "\"\\\"\\\\\\\"\\\\\\\\\\\\\\\"\\\\\\\\\\\\\\\`\\\\\\\"\\\"\""echo "\"\\\"\\\\\\\"\\\\\\\\\\\\\\\"\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\\\\\\\\"\\\\\\\"\\\"\""pwd"\"\\\"\\\\\\\"\\\\\\\\\\\\\\\"\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\\\\\\\\"\\\\\\\\\\\\\\\`\\\\\\\\\\\\\\\"\\\\\\\"\\\\\\\`\\\\\\\"\\\"\\\`\\\"\"\`\""`"
</syntaxhighlight>

==== Background execution ====

Normally, when the C shell starts a command, it waits for the command to finish before giving the user another prompt signaling that a new command can be typed.

*''command''<code> &</code> means start ''command'' in the background and prompt immediately for a new command.

==== Subshells ====

A subshell is a separate child copy of the shell that inherits the current state but can then make changes, e.g., to the current directory, without affecting the parent.

*<code>( </code>''commands''<code> )</code> means run ''commands'' in a subshell.

=== Control structures ===

The C shell provides control structures for both [[Conditional (programming)|condition-testing]] and [[iteration]].  The condition-testing control structures are the if and switch statements.  The iteration control structures are the while, foreach and repeat statements.

==== if statement ====

There are two forms of the [[if statement]].  The short form is typed on a single line but can specify only a single command if the expression is true.

<syntaxhighlight lang="csh">if ( expression ) command</syntaxhighlight>

The long form uses then, else and endif keywords to allow for blocks of commands to be nested inside the condition.

<syntaxhighlight lang="csh">
if ( expression1 ) then
    commands
else if ( expression2 ) then
    commands
    ...
else
    commands
endif
</syntaxhighlight>

If the else and if keywords appear on the same line, csh chains, rather than nests them; the block is terminated with a single endif.

==== switch statement ====

The switch statement compares a string against a list of patterns, which may contain wildcard characters.  If nothing matches, the default action, if there is one, is taken.

<syntaxhighlight lang="csh">
switch ( string )
    case pattern1:
        commands
        breaksw
    case pattern2:
        commands
        breaksw
        ...
    default:
        commands
        breaksw
endsw
</syntaxhighlight>

==== while statement ====

The [[While loop|while statement]] evaluates an expression.  If it is true, the shell runs the nested commands and then repeats for as long as the expression remains true.

<syntaxhighlight lang="csh">
while ( expression )
    commands
end
</syntaxhighlight>

==== foreach statement ====

The foreach statement takes a list of values, usually a list of filenames produced by wildcarding, and then for each, sets the loop variable to that value and runs the nested commands.

<syntaxhighlight lang="csh">
foreach loop-variable ( list-of-values )
    commands
end
</syntaxhighlight>

==== repeat statement ====

The repeat statement repeats a single command an integral number of times.

<syntaxhighlight lang="csh">repeat integer command</syntaxhighlight>

=== Variables ===

The C shell implements both shell and [[environment variable]]s.<ref name="USDT">{{cite book
 | last = Troy
 | first = Douglas
 | title = UNIX Systems
 | publisher = Benjamin/Cumming Publishing Company
 | series = Computing Fundamentals
 | date = 1990
 | pages = 25
 }}</ref> Environment variables, created using the <code>setenv</code> statement, are always simple strings, passed to any [[Process (computing)|child processes]], which retrieve these variables via the [[exec (system call)#envp|<code>envp[]</code>]] argument to [[Main function (programming)|<code>main()</code>]].

Shell variables, created using the <code>set</code> or <code>@</code> statements, are internal to C shell.  They are not passed to child processes.  Shell variables can be either simple strings or arrays of strings.  Some of the shell variables are predefined and used to control various internal C shell options, e.g., what should happen if a wildcard fails to match anything.

In current versions of csh, strings can be of arbitrary length, well into millions of characters.

Variables can be enlarged as needed. However, if it's desirable to work on a fixed size, the following syntax is preferred.

<syntaxhighlight lang="csh">
# Creates a variable large enough to hold 1024 elements.
set fixed = {,}{,}{,}{,}{,}{,}{,}{,}{,}{,}
</syntaxhighlight>

=== Expressions ===

The C shell implements a 32-bit integer expression grammar with operators borrowed from C but with a few additional operators for string comparisons and filesystem tests, e.g., testing for the existence of a file.  Operators must be separated by whitespace from their operands.  Variables are referenced as <code>$</code>''name''.

[[Operator precedence#Programming languages|Operator precedence]] is also borrowed from C, but with different [[operator associativity]] rules to resolve the ambiguity of what comes first in a sequence of equal precedence operators.  In C, the associativity is left-to-right for most operators; in C shell, it is right-to-left.  For example,

{{column
|width=60em
|1=
<syntaxhighlight lang="c">
// C groups from the left
int i = 10 / 5 * 2;
printf( "%d\n", i ); // prints 4
i = 7 - 4 + 2;
printf( "%d\n", i ); // prints 5
i = 2 >> 1 << 4;
printf( "%d\n", i ); // prints 16
</syntaxhighlight>
|2=
<syntaxhighlight lang="csh">
# C shell groups from the right
@ i = 10 / 5 * 2
echo $i # prints 1
@ i = 7 - 4 + 2
echo $i # prints 1
@ i = ( 2 >> 1 << 4 )
echo $i # prints 0
</syntaxhighlight>
}}

The parentheses in the C shell example are to avoid having the bit-shifting operators confused as I/O redirection operators.  In either language, parentheses can always be used to explicitly specify the desired order of evaluation, even if only for clarity.

Return values are limited to 8-bit. For <code>exit</code> expressions, the unary negation operator can be used for 32-bit evaluation.

<syntaxhighlight lang="csh">
exit ! ! 256 # Returns 1.
</syntaxhighlight>

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

== Influence ==
[[File:Hamilton C shell x64 on Windows 7.png|thumb|300px|right|64-bit [[Hamilton C shell]] on a [[Windows 7]] desktop]]
The C shell was extremely successful in introducing a large number of innovations including the [[C shell#History|history]] mechanism, [[C shell#Aliases|aliases]], [[C shell#Tilde notation|tilde notation]], interactive filename completion, an expression grammar built into the shell, and more, that have since been copied by other Unix shells.  But in contrast to [[Bourne shell|sh]], which has spawned a large number of independently developed clones, including [[KornShell|ksh]] and [[Bash (Unix shell)|bash]], only two csh [[Clone (computing)|clones]] are known.  (Since [[tcsh]] was based on the csh code originally written by Bill Joy, it is not considered a clone.)

In 1986, [[Allen Holub]] wrote ''On Command: Writing a Unix-Like Shell for [[MS-DOS]]'',<ref>
{{cite book
  | first = Allen
  | last = Holub
  | author-link = Allen Holub
  | date = 1986{{ndash}}1987
  | edition = Second
  | title = On Command: Writing a Unix-Like Shell for MS-DOS
  | publisher = M&T Books, Redwood City, CA
  | isbn = 0-934375-29-1}}
</ref> a book describing a program he had written called "SH" but which in fact copied the language design and features of csh, not sh.  Companion diskettes containing full source for SH and for a basic set of Unix-like utilities (cat, cp, grep, etc.) were available for $25 and $30, respectively, from the publisher.  The control structures, expression grammar, history mechanism and other features in Holub's SH were identical to those of the C shell.

In 1988, Hamilton Laboratories began shipping [[Hamilton C shell]] for [[OS/2]].<ref>{{cite journal
 |last         = Hamilton
 |first        = Douglas
 |title        = Hamilton C shell Announcement
 |journal      = IBM Personal Systems Developer
 |issue        = Summer 1989
 |pages        = 119–121
 |url          = http://hamiltonlabs.com/Archives/Hamilton-C-Shell-Announcement-Douglas-A-Hamilton-IBM-Personal-Systems-Developer-Summer-1989.pdf
 |access-date   = 11 July 2020
}}</ref> It included both a csh clone and a set of Unix-like utilities. In 1992, Hamilton C shell was released for [[Windows NT]].<ref name=HamiltonReleaseNotes>
{{cite web
  | title = Hamilton C shell for Windows Release Notes 5.2.g
  | last = Hamilton
  | first = Nicole
  | url = http://hamiltonlabs.com/ReleaseNotes.htm
  | publisher = Hamilton Laboratories, Redmond, WA
  | date = 5 March 2017
  | access-date = 3 April 2018
}}
</ref> The Windows version continues to be actively supported but the OS/2 version was discontinued in 2003.<ref name=HamiltonReleaseNotes/> An early 1990 quick reference<ref>{{cite book
 |title        = Hamilton C shell Quick Reference
 |publisher    = Hamilton Laboratories, Wayland, MA
 |date         = 1988{{ndash}}1990
 |url          = http://hamiltonlabs.com/Archives/1990-07-10-Hamilton-C-shell-Quick-Reference.pdf
 |access-date   = 11 July 2020
}}</ref> described the intent as "full compliance with the entire C shell language (except [[C shell#Job control|job control]])" but with improvements to the language design and adaptation to the differences between Unix and a PC.  The most important improvement was a [[Top-down parsing|top-down parser]] that allowed [[control structure]]s to be nested or piped, something the original C shell could not support, given its ad hoc parser.  Hamilton also added new language features including built-in and user-defined procedures, block-structured local variables and floating point arithmetic.  Adaptation to a PC included support for the filename and other conventions on a PC and the use of [[Thread (computer science)|threads]] instead of [[Fork (system call)|forks]] (which were not available under either OS/2 or Windows) to achieve [[Parallel computing|parallelism]], e.g., in setting up a pipeline.

== See also ==
* [[Command-line interpreter]]
* [[Comparison of command shells]]

== References ==
{{reflist}}

== Further reading ==
*{{cite book
    | first = Gail
    | last = Anderson
    | author2 = Paul Anderson
    | year = 1986
    | title = The UNIX C Shell Field Guide
    | publisher = Prentice-Hall
    | isbn = 0-13-937468-X
    | url = https://archive.org/details/unixcshellfieldg00ande
    }}
*{{cite book
    | first = Paul
    | last = Wang
    | year = 1988
    | title = An Introduction to Berkeley UNIX
    | publisher = Wadsworth Pub. Co.
    | isbn = 0-534-08862-7
    | url-access = registration
    | url = https://archive.org/details/introductiontobe0000wang
    }}
*{{cite book
    | first = Paul
    | last = DuBois
    | year = 1995
    | title = Using csh & tcsh
    | publisher = O'Reilly & Associates
    | isbn = 1-56592-132-1
    | url = https://archive.org/details/usingcshtcsh00dubo
    }}
*{{cite book
    | first = Martin R.
    | last = Arick
    | year = 1993
    | title = UNIX C Shell Desk Reference
    | publisher = John Wiley & Sons
    | isbn = 0-471-55680-7
    }}
*{{cite web
  | title = Introduction to C Shell Programming
  | publisher = Canisius College Computer Science Department
  | url = http://klaatu.canisius.edu/ONLINESTUFF/UNIX/shellprogramming.html
  | access-date = 23 June 2010}}

== External links ==
{{wikibooks|C Shell Scripting}}
*[https://docs.freebsd.org/44doc/usd/04.csh/paper.html ''An Introduction to the C shell''] by [[Bill Joy|William Joy]].
*[https://docstore.mik.ua/orelly/linux/lnut/ch08_01.htm Linux in a Nutshell:  Chapter 8. csh and tcsh].
*[https://web.archive.org/web/20100212221424/http://www.tcsh.org/Home tcsh home page].
*[https://web.archive.org/web/20160419222736/http://www.tcsh.org/tcsh.html/top.html tcsh(1) man page].
*[https://github.com/tcsh-org/tcsh most recent available tcsh source code].
*[https://minnie.tuhs.org/cgi-bin/utree.pl?file=2BSD/src/csh historical 2BSD csh source code] dated 2 February 1980.
*[https://minnie.tuhs.org/cgi-bin/utree.pl The Unix Tree], complete historical Unix distributions.
*[http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/ Csh programming considered harmful].
*[https://www.grymoire.com/Unix/CshTop10.txt Top Ten Reasons not to use the C shell].

{{Unix Shells}}

{{DEFAULTSORT:C Shell}}
[[Category:1978 software]]
[[Category:Cross-platform free software]]
[[Category:Unix shells]]
[[Category:Software using the BSD license]]