This article introduces the tcsh in detail. And the most of the content is from Tcsh Manual v6.19.00. I try to understand all features and add some examples in this article.

Instruction

The official website of Tcsh is here.

What’s csh?

The C shell (csh) is a Unix shell that was created by Bill Joy while he was a graduate student at University of California, Berkeley in the late 1970s. It has been distributed widely, beginning with the 2BSD release of the BSD Unix system that Joy began distributing in 1978. Other early contributors to the ideas or the code were Michael Ubell, Eric Allman, Mike O’Brien and Jim Kulp.

The C shell is a command processor typically run in a text window, allowing the user to type commands. The C shell can also read commands from a file, called a script. Like all Unix shells, it supports filename wildcarding, piping, here documents, command substitution, variables and control structures for 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 and was seen as more readable.

What’s Tcsh?

Tcsh is a Unix shell based on and compatible with the C shell (csh). It is essentially the C shell with programmable command-line completion, command-line editing, and a few other features. Unlike the other common shells, functions cannot be defined in a tcsh script and the user must use aliases instead (as in csh).

The t in tcsh comes from the T in TENEX, an operating system which inspired Ken Greer at Carnegie Mellon University, the author of tcsh, with its command-completion feature. Greer began working on his code to implement Tenex-style file name completion in September 1975, finally merging it into the C shell in December 1981. Mike Ellis at Fairchild A.I. Labs added command completion in September 1983. On October 3, 1983, Greer posted source to the net.sources newsgroup.

Tcsh Releases

SYNOPSIS

Formats: tcsh [-bcdefFimnqstvVxX] [-Dname[=value]] [arg ...] tcsh -l

If the first argument (argument 0) to the shell is - then it is a login shell. A login shell can be also specified by invoking the shell with the -l flag as the only argument.

The rest of the flag arguments are interpreted as follows:

After processing of flag arguments, if arguments remain but none of the -c, -i, -s, or -t options were given, the first argument is taken as the name of a file of commands, or script, to be executed. The shell opens this file and saves its name for possible resubstitution by $0. Because many systems use either the standard version 6 or version 7 shells whose shell scripts are not compatible with this shell, the shell uses such a standard shell to execute a script whose first character is not a #, i.e., that does not start with a comment.

Remaining arguments are placed in the argv shell variable.

DESCRIPTION

Startup and shutdown

A login shell begins by executing commands from the system files /etc/csh.cshrc and /etc/csh.login. It then executes commands from files in the user’s home directory: first ~/.tcshrc (+) or, if ~/.tcshrc is not found, ~/.cshrc, then ~/.history (or the value of the histfile shell variable), then ~/.login, and finally ~/.cshdirs (or the value of the dirsfile shell variable) (+). The shell may read /etc/csh.login before instead of after /etc/csh.cshrc, and ~/.login before instead of after ~/.tcshrc or ~/.cshrc and ~/.history, if so compiled; see the version shell variable. (+)

Non-login shells read only /etc/csh.cshrc and ~/.tcshrc or ~/.cshrc on startup.

For examples of startup files, please consult the tcshrc project.

Commands like stty(1) and tset(1), which need be run only once per login, usually go in one’s ~/.login file. Users who need to use the same set of files with both csh(1) and tcsh can have only a ~/.cshrc which checks for the existence of the tcsh shell variable (q.v.) before using tcsh-specific commands, or can have both a ~/.cshrc and a ~/.tcshrc which sources (see the builtin command) ~/.cshrc. The rest of this manual uses ~/.tcshrc to mean ~/.tcshrc or, if ~/.tcshrc is not found, ~/.cshrc.

In the normal case, the shell begins reading commands from the terminal, prompting with >. (Processing of arguments and the use of the shell to process files containing command scripts are described later.) The shell repeatedly reads a line of command input, breaks it into words, places it on the command history list, parses it and executes each command in the line.

One can log out by typing ^D on an empty line, logout or login or via the shell’s autologout mechanism (see the autologout shell variable). When a login shell terminates it sets the logout shell variable to normal or automatic as appropriate, then executes commands from the files /etc/csh.logout and ~/.logout. The shell may drop DTR on logout if so compiled; see the version shell variable.

The names of the system login and logout files vary from system to system for compatibility with different csh(1) variants; see FILES.

When startup, the shell begins by executing commands from the following system files:

Note: The shell may read /etc/csh.login before instead of after /etc/csh.cshrc, and ~/.login before instead of after ~/.tcshrc or ~/.cshrc and ~/.history, if so compiled; see the version shell variable. (+)

When a login shell terminates, the shell begins by executing commands from the following system files:

The command-line editor (+)

Command-line input can be edited using key sequences much like those used in emacs(1) or vi(1). The editor is active only when the edit shell variable is set, which it is by default in interactive shells. The bindkey builtin can display and change key bindings. emacs(1)-style key bindings are used by default (unless the shell was compiled otherwise; see the version shell variable), but bindkey can change the key bindings to vi(1)-style bindings en masse.

The shell always binds the arrow keys (as defined in the TERMCAP environment variable) to

unless doing so would alter another single-character binding. One can set the arrow key escape sequences to the empty string with settc to prevent these bindings. The ANSI/VT100 sequences for arrow keys are always bound.

Other key bindings are, for the most part, what emacs(1) and vi(1) users would expect and can easily be displayed by bindkey, so there is no need to list them here. Likewise, bindkey can list the editor commands with a short description of each. Certain key bindings have different behavior depending if emacs(1) or vi(1) style bindings are being used; see vimode for more information.

Note that editor commands do not have the same notion of a word as does the shell. The editor delimits words with any non-alphanumeric characters not in the shell variable wordchars, while the shell recognizes only whitespace and some of the characters with special meanings to it, listed under Lexical structure.

Examples:

chenwx@chenwx ~ $ tcsh
chenwx:~> bindkey
Standard key bindings
"^@"           ->  set-mark-command
"^A"           ->  beginning-of-line
"^B"           ->  backward-char
"^C"           ->  tty-sigintr
"^D"           ->  delete-char-or-list-or-eof
"^E"           ->  end-of-line
"^F"           ->  forward-char
"^G"           ->  is undefined
"^H"           ->  backward-delete-char
"^I"           ->  complete-word
"^J"           ->  newline
"^K"           ->  kill-line
"^L"           ->  clear-screen
...

Completion and listing (+)

The shell is often able to complete words when given a unique abbreviation. Type part of a word (for example ls /usr/lost) and hit the tab key to run the complete-word editor command. The shell completes the filename /usr/lost to /usr/lost+found/, replacing the incomplete word with the complete word in the input buffer. (Note the terminal /; completion adds a / to the end of completed directories and a space to the end of other completed words, to speed typing and provide a visual indicator of successful completion. The addsuffix shell variable can be unset to prevent this.) If no match is found (perhaps /usr/lost+found doesn’t exist), the terminal bell rings. If the word is already complete (perhaps there is a /usr/lost on your system, or perhaps you were thinking too far ahead and typed the whole thing) a / or space is added to the end if it isn’t already there.

Completion works anywhere in the line, not at just the end; completed text pushes the rest of the line to the right. Completion in the middle of a word often results in leftover characters to the right of the cursor that need to be deleted.

Commands and variables can be completed in much the same way. For example, typing em[tab] would complete em to emacs if emacs were the only command on your system beginning with em. Completion can find a command in any directory in path or if given a full pathname. Typing echo $ar[tab] would complete $ar to $argv if no other variable began with ar.

The shell parses the input buffer to determine whether the word you want to complete should be completed as a filename, command or variable. The first word in the buffer and the first word following ;, |, |&, && or || is considered to be a command. A word beginning with $ is considered to be a variable. Anything else is a filename. An empty line is completed as a filename.

You can list the possible completions of a word at any time by typing ^D to run the delete-char-or-list-or-eof editor command. The shell lists the possible completions using the ls-F builtin (q.v.) and reprints the prompt and unfinished command line, for example:

> ls /usr/l[^D]
lbin/ lib/ local/ lost+found/
> ls /usr/l

If the autolist shell variable is set, the shell lists the remaining choices (if any) whenever completion fails:

> set autolist
> nm /usr/lib/libt[tab]
libtermcap.a@ libtermlib.a@
> nm /usr/lib/libterm

If autolist is set to ambiguous, choices are listed only when completion fails and adds no new characters to the word being completed.

A filename to be completed can contain variables, your own or others’ home directories abbreviated with ~ (see Filename substitution) and directory stack entries abbreviated with = (see Directory stack substitution). For example,

> ls ~k[^D]
kahn kas kellogg
> ls ~ke[tab]
> ls ~kellogg/

or

> set local = /usr/local
> ls $lo[tab]
> ls $local/[^D]
bin/ etc/ lib/ man/ src/
> ls $local/

Note that variables can also be expanded explicitly with the expand-variables editor command.

delete-char-or-list-or-eof lists at only the end of the line; in the middle of a line it deletes the character under the cursor and on an empty line it logs one out or, if ignoreeof is set, does nothing. M-^D, bound to the editor command list-choices, lists completion possibilities anywhere on a line, and list-choices (or any one of the related editor commands that do or don’t delete, list and/or log out, listed under delete-char-or-list-or-eof) can be bound to ^D with the bindkey builtin command if so desired.

The complete-word-fwd and complete-word-back editor commands (not bound to any keys by default) can be used to cycle up and down through the list of possible completions, replacing the current word with the next or previous word in the list.

The shell variable fignore can be set to a list of suffixes to be ignored by completion. Consider the following:

> ls
Makefile condiments.h~ main.o side.c
README main.c meal side.o
condiments.h main.c~
> set fignore = (.o \~)
> emacs ma[^D]
main.c main.c~ main.o
> emacs ma[tab]
> emacs main.c

main.c~ and main.o are ignored by completion (but not listing), because they end in suffixes in fignore. Note that a \ was needed in front of ~ to prevent it from being expanded to home as described under Filename substitution. fignore is ignored if only one completion is possible.

If the complete shell variable is set to enhance, completion 1) ignores case and 2) considers periods, hyphens and underscores (., - and _) to be word separators and hyphens and underscores to be equivalent. If you had the following files

comp.lang.c comp.lang.perl comp.std.c++ comp.lang.c++ comp.std.c

and typed mail -f c.l.c[tab], it would be completed to mail -f comp.lang.c, and ^D would list comp.lang.c and comp.lang.c++. mail -f c..c++[^D] would list comp.lang.c++ and comp.std.c++. Typing rm a--file[^D] in the following directory

A_silly_file a-hyphenated-file another_silly_file

would list all three files, because case is ignored and hyphens and underscores are equivalent. Periods, however, are not equivalent to hyphens or underscores.

If the complete shell variable is set to Enhance, completion ignores case and differences between a hyphen and an underscore word separator only when the user types a lowercase character or a hyphen. Entering an uppercase character or an underscore will not match the corresponding lowercase character or hyphen word separator. Typing rm a--file[^D] in the directory of the previous example would still list all three files, but typing rm A--file would match only A_silly_file and typing rm a__file[^D] would match just A_silly_file and another_silly_file because the user explicitly used an uppercase or an underscore character.

Completion and listing are affected by several other shell variables:

recexact can be set to complete on the shortest possible unique match, even if more typing might result in a longer match:

> ls
fodder foo food foonly
> set recexact
> rm fo[tab]

just beeps, because fo could expand to fod or foo, but if we type another o,

> rm foo[tab]
> rm foo

the completion completes on foo, even though food and foonly also match.

autoexpand can be set to run the expand-history editor command before each completion attempt.

autocorrect can be set to spelling-correct the word to be completed (see Spelling correction) before each completion attempt and correct can be set to complete commands automatically after one hits return.

matchbeep can be set to make completion beep or not beep in a variety of situations;

nobeep can be set to never beep at all.

nostat can be set to a list of directories and/or patterns that match directories to prevent the completion mechanism from stat(2)ing those directories.

listmax and listmaxrows can be set to limit the number of items and rows (respectively) that are listed without asking first.

recognize_only_executables can be set to make the shell list only executables when listing commands, but it is quite slow.

Finally, the complete builtin command can be used to tell the shell how to complete words other than filenames, commands and variables. Completion and listing do not work on glob-patterns (see Filename substitution), but the list-glob and expand-glob editor commands perform equivalent functions for glob-patterns.

Spelling correction (+)

The shell can sometimes correct the spelling of filenames, commands and variable names as well as completing and listing them.

Individual words can be spelling-corrected with the spell-word editor command (usually bound to M-s and M-S) and the entire input buffer with spell-line (usually bound to M-$). The correct shell variable can be set to cmd to correct the command name or all to correct the entire line each time return is typed, and autocorrect can be set to correct the word to be completed before each completion attempt.

When spelling correction is invoked in any of these ways and the shell thinks that any part of the command line is misspelled, it prompts with the corrected line:

> set correct = cmd
> lz /usr/bin
CORRECT>ls /usr/bin (y|n|e|a)?

One can answer:

• y or space to execute the corrected line,
• e to leave the uncorrected command in the input buffer,
• a to abort the command as if ^C had been hit, and
• anything else to execute the original line unchanged.

Spelling correction recognizes user-defined completions (see the complete builtin command). If an input word in a position for which a completion is defined resembles a word in the completion list, spelling correction registers a misspelling and suggests the latter word as a correction. However, if the input word does not match any of the possible completions for that position, spelling correction does not register a misspelling.

Like completion, spelling correction works anywhere in the line, pushing the rest of the line to the right and possibly leaving extra characters to the right of the cursor.

Editor commands (+)

bindkey lists key bindings and bindkey -l lists and briefly describes editor commands. Only new or especially interesting editor commands are described here. See emacs(1) and vi(1) for descriptions of each editor’s key bindings.

^character means a control character and M-character a meta character, typed as escape-character on terminals without a meta key. Case counts, but commands that are bound to letters by default are bound to both lower- and uppercase letters for convenience.

Lexical structure

The shell splits input lines into words at blanks and tabs. The special characters & | ; < > ( ) and the doubled characters && || << >> are always separate words, whether or not they are surrounded by whitespace.

When the shell’s input is not a terminal, the character # is taken to begin a comment. Each # and the rest of the input line on which it appears is discarded before further parsing.

A special character (including a blank or tab) may be prevented from having its special meaning, and possibly made part of another word, by preceding it with a backslash (\) or enclosing it in single ('), double (") or backward (\`) quotes. When not otherwise quoted a newline preceded by a \' is equivalent to a blank, but inside quotes this sequence results in a newline.

Furthermore, all Substitutions except History substitution can be prevented by enclosing the strings (or parts of strings) in which they appear with single quotes or by quoting the crucial character(s) (e.g., $ or \` for Variable substitution or Command substitution respectively) with \. (Alias substitution is no exception: quoting in any way any character of a word for which an alias has been defined prevents substitution of the alias. The usual way of quoting an alias is to precede it with a backslash.) History substitution is prevented by backslashes but not by single quotes. Strings quoted with double or backward quotes undergo Variable substitution and Command substitution, but other substitutions are prevented.

Text inside single or double quotes becomes a single word (or part of one). Metacharacters in these strings, including blank and tabs, do not form separate words. Only in one special case (see Command substitution) can a double-quoted string yield parts of more than one word; single-quoted strings never do. Backward quotes are special: they signal Command substitution (q.v.), which may result in more than one word.

Quoting complex strings, particularly strings which themselves contain quoting characters, can be confusing. Remember that quotes need not be used as they are in human writing! It may be easier to quote not an entire string, but only those parts of the string which need quoting, using different types of quoting to do so if appropriate.

The backslash_quote shell variable (q.v.) can be set to make backslashes always quote \, ', and ". (+) This may make complex quoting tasks easier, but it can cause syntax errors in csh(1) scripts.

Substitutions

We now describe the various transformations the shell performs on the input in the order in which they occur. We note in passing the data structures involved and the commands and variables which affect them. Remember that substitutions can be prevented by quoting as described under Lexical structure.

History substitution

Each command, or event, input from the terminal is saved in the history list. The previous command is always saved, and the history shell variable can be set to a number to save that many commands. The histdup shell variable can be set to not save duplicate events or consecutive duplicate events.

Saved commands are numbered sequentially from 1 and stamped with the time. It is not usually necessary to use event numbers, but the current event number can be made part of the prompt by placing an ! in the prompt shell variable.

The shell actually saves history in expanded and literal (unexpanded) forms. If the histlit shell variable is set, commands that display and store history use the literal form.

The history builtin command can print, store in a file, restore and clear the history list at any time, and the savehist and histfile shell variables can be set to store the history list automatically on logout and restore it on login.

History substitutions introduce words from the history list into the input stream, making it easy to repeat commands, repeat arguments of a previous command in the current command, or fix spelling mistakes in the previous command with little typing and a high degree of confidence.

History substitutions begin with the character !. They may begin anywhere in the input stream, but they do not nest. The ! may be preceded by a \ to prevent its special meaning; for convenience, a ! is passed unchanged when it is followed by a blank, tab, newline, = or (. History substitutions also occur when an input line begins with ^. This special abbreviation will be described later. The characters used to signal history substitution (! and ^) can be changed by setting the histchars shell variable. Any input line which contains a history substitution is printed before it is executed.

A history substitution may have an event specification, which indicates the event from which words are to be taken, a word designator, which selects particular words from the chosen event, and/or a modifier, which manipulates the selected words.

An event specification can be

For example, consider this bit of someone’s history list:

9 8:30 nroff -man wumpus.man
10 8:31 cp wumpus.man wumpus.man.old
11 8:36 vi wumpus.man
12 8:37 diff wumpus.man.old wumpus.man

The commands are shown with their event numbers and time stamps. The current event, which we haven’t typed in yet, is event 13. !11 and !-2 refer to event 11. !! refers to the previous event, 12. !! can be abbreviated ! if it is followed by :. !n refers to event 9, which begins with n. !?old? also refers to event 12, which contains old. Without word designators or modifiers history references simply expand to the entire event, so we might type !cp to redo the copy command or !!|more if the diff output scrolled off the top of the screen.

History references may be insulated from the surrounding text with braces if necessary. For example, !vdoc would look for a command beginning with vdoc, and, in this example, not find one, but !{v}doc would expand unambiguously to vi wumpus.mandoc. Even in braces, history substitutions do not nest.

(+) While csh(1) expands, for example, !3d to event 3 with the letter d appended to it, tcsh expands it to the last event beginning with 3d; only completely numeric arguments are treated as event numbers. This makes it possible to recall events beginning with numbers. To expand !3d as in csh(1) say !{3}d.

To select words from an event we can follow the event specification by a : and a designator for the desired words. The words of an input line are numbered from 0, the first (usually command) word being 0, the second word (first argument) being 1, etc. The basic word designators are:

Selected words are inserted into the command line separated by single blanks. For example, the diff command in the previous example might have been typed as diff !!:1.old !!:1 (using :1 to select the first argument from the previous event) or diff !-2:2 !-2:1 to select and swap the arguments from the cp command. If we didn’t care about the order of the diff we might have said diff !-2:1-2 or simply diff !-2:*. The cp command might have been written cp wumpus.man !#:1.old, using # to refer to the current event. !n:- hurkle.man would reuse the first two words from the nroff command to say nroff -man hurkle.man.

The : separating the event specification from the word designator can be omitted if the argument selector begins with a ^, $, *, % or -. For example, our diff command might have been diff !!^.old !!^ or, equivalently, diff !!$.old !!$. However, if !! is abbreviated !, an argument selector beginning with - will be interpreted as an event specification.

A history reference may have a word designator but no event specification. It then references the previous command. Continuing our diff example, we could have said simply diff !^.old !^ or, to get the arguments in the opposite order, just diff !*.

Alias substitution

TBD

Variable substitution

TBD

Command, filename and directory stack substitution

TBD

Command substitution

TBD

Filename substitution

TBD

Directory stack substitution (+)

TBD

Other substitutions (+)

TBD

Commands

Simple commands, pipelines and sequences

TBD

Builtin and non-builtin command execution

TBD

Input/output

TBD

Features

Control flow

TBD

Expressions

TBD

Logical, arithmetical and comparison operators

TBD

Command exit status

TBD

File inquiry operators

TBD

Jobs

Status reporting

TBD

Automatic, periodic and timed events (+)

TBD

Native Language System support (+)

TBD

OS variant support (+)

TBD

Signal handling

TBD

Terminal management (+)

TBD

REFERENCE

Builtin commands

if

Format #1:

if (expr) command

If expr (an expression, as described under Expressions) evaluates true, then command is executed. Variable substitution on command happens early, at the same time it does for the rest of the if command. command must be a simple command, not an alias, a pipeline, a command list or a parenthesized command list, but it may have arguments. Input/output redirection occurs even if expr is false and command is thus not executed; this is a bug.

Format #2:

if (expr) then
    ...
else if (expr2) then
    ...
else
    ...
endif

If the specified expr is true then the commands to the first else are executed; otherwise if expr2 is true then the commands to the second else are executed, etc. Any number of else-if pairs are possible; only one endif is needed. The else part is likewise optional. (The words else and endif must appear at the beginning of input lines; the if must appear alone on its input line or after an else.)

switch

Format:

switch (string)
case str1:
    ...
    breaksw

case str2:
    ...
    breaksw

...

default:
    ...
    breaksw

endsw

Each case label is successively matched, against the specified string which is first command and filename expanded. The file metacharacters *, ? and [...] may be used in the case labels, which are variable expanded. If none of the labels match before a default label is found, then the execution begins after the default label. Each case label and the default label must appear at the beginning of a line. The command breaksw causes execution to continue after the endsw. Otherwise control may fall through case labels and default labels as in C. If no label matches and there is no default, execution continues after the endsw.

foreach

Format:

foreach name (wordlist)
    ...
    break
    ...
    continue
    ...
end

Successively sets the variable name to each member of wordlist and executes the sequence of commands between this command and the matching end. (Both foreach and end must appear alone on separate lines.) The builtin command continue may be used to continue the loop prematurely and the builtin command break to terminate it prematurely. When this command is read from the terminal, the loop is read once prompting with foreach? (or prompt2) before any statements in the loop are executed. If you make a mistake typing in a loop at the terminal you can rub it out.

while

Format:

while (expr)
    ...
    break
    ...
    continue
    ...
end

Special aliases (+)

If set, each of these aliases executes automatically at the indicated time. They are all initially undefined.

Special shell variables

ENVIRONMENT

FILES

The order in which startup files are read may differ if the shell was so compiled.

NEW FEATURES (+)

THE T IN TCSH

In 1964, DEC produced the PDP-6. The PDP-10 was a later re-implementation. It was re-christened the DECsystem-10 in 1970 or so when DEC brought out the second model, the KI10.

TENEX was created at Bolt, Beranek & Newman (a Cambridge, Massachusetts think tank) in 1972 as an experiment in demand-paged virtual memory operating systems. They built a new pager for the DEC PDP-10 and created the OS to go with it. It was extremely successful in academia.

In 1975, DEC brought out a new model of the PDP-10, the KL10; they intended to have only a version of TENEX, which they had licensed from BBN, for the new box. They called their version TOPS-20 (their capitalization is trademarked). A lot of TOPS-10 users (The OPerating System for PDP-10) objected; thus DEC found themselves supporting two incompatible systems on the same hardware – but then there were 6 on the PDP-11!

TENEX, and TOPS-20 to version 3, had command completion via a user-code-level subroutine library called ULTCMD. With version 3, DEC moved all that capability and more into the monitor (‘kernel’ for you Unix types), accessed by the COMND% JSYS (‘Jump to SYStem’ instruction, the supervisor call mechanism).

The creator of tcsh was impressed by this feature and several others of TENEX and TOPS-20, and created a version of csh which mimicked them.

LIMITATIONS

The system limits argument lists to ARG_MAX characters.

The number of arguments to a command which involves filename expansion is limited to 1/6th the number of characters allowed in an argument list.

Command substitutions may substitute no more characters than are allowed in an argument list.

To detect looping, the shell restricts the number of alias substitutions on a single line to 20.

References

• Tcsh Manual
• Download Tcsh (US)
• Download Tcsh (Finland)