An instance of csh begins by executing commands from the file `.cshrc' in the home directory of the invoker. If this is a login shell then it also executes commands from the file `.login' there. It is typical for users on crt's to put the command ``stty crt'' in their .login file, and to also invoke tset(1) there.
In the normal case, the shell will then begin reading commands from the terminal, prompting with `% '. Processing of arguments and the use of the shell to process files containing command scripts will be described later.
The shell then repeatedly performs the following actions: a line of command input is read and broken into words. This sequence of words is placed on the command history list and then parsed. Finally each command in the current line is executed.
When a login shell terminates it executes commands from the file `.logout'
in the users home directory.
Lexical structure
The shell splits input lines into words at blanks and tabs with the following exceptions. The characters `&' `|' `;' `<' `>' `(' `)' form separate words. If doubled in `&&', `||', `<<' or `>>' these pairs form single words. These parser metacharacters may be made part of other words, or prevented their special meaning, by preceding them with `\'. A newline preceded by a `\' is equivalent to a blank.
In addition strings enclosed in matched pairs of quotations, `'', ``' or `"', form parts of a word; metacharacters in these strings, including blanks and tabs, do not form separate words. These quotations have semantics to be described subsequently. Within pairs of `'' or `"' characters a newline preceded by a `\' gives a true newline character.
When the shell's input is not a terminal,
the character `#' introduces a comment which continues to the end of the
input line.
It is prevented this special meaning when preceded by `\'
and in quotations using ``', `'', and `"'.
Commands
A simple command is a sequence of words, the first of which specifies the command to be executed. A simple command or a sequence of simple commands separated by `|' characters forms a pipeline. The output of each command in a pipeline is connected to the input of the next. Sequences of pipelines may be separated by `;', and are then executed sequentially. A sequence of pipelines may be executed without immediately waiting for it to terminate by following it with an `&'.
Any of the above may be placed in `(' `)' to form a simple command (which
may be a component of a pipeline, etc.)
It is also possible to separate pipelines with `||' or `&&' indicating,
as in the C language,
that the second is to be executed only if the first fails or succeeds
respectively. (See
Expressions.)
Jobs
The shell associates a job with each pipeline. It keeps a table of current jobs, printed by the jobs command, and assigns them small integer numbers. When a job is started asynchronously with `&', the shell prints a line which looks like:
[1] 1234
indicating that the job which was started asynchronously was job number 1 and had one (top-level) process, whose process id was 1234.
If you are running a job and wish to do something else you may hit the key ^Z (control-Z) which sends a STOP signal to the current job. The shell will then normally indicate that the job has been `Stopped', and print another prompt. You can then manipulate the state of this job, putting it in the background with the bg command, or run some other commands and then eventually bring the job back into the foreground with the foreground command fg. A ^Z takes effect immediately and is like an interrupt in that pending output and unread input are discarded when it is typed. There is another special key ^Y which does not generate a STOP signal until a program attempts to read(2) it. This can usefully be typed ahead when you have prepared some commands for a job which you wish to stop after it has read them.
A job being run in the background will stop if it tries to read from the terminal. Background jobs are normally allowed to produce output, but this can be disabled by giving the command ``stty tostop''. If you set this tty option, then background jobs will stop when they try to produce output like they do when they try to read input.
There are several ways to refer to jobs in the shell. The character `%' introduces a job name. If you wish to refer to job number 1, you can name it as `%1'. Just naming a job brings it to the foreground; thus `%1' is a synonym for `fg %1', bringing job 1 back into the foreground. Similarly saying `%1 &' resumes job 1 in the background. Jobs can also be named by prefixes of the string typed in to start them, if these prefixes are unambiguous, thus `%ex' would normally restart a suspended ex(1) job, if there were only one suspended job whose name began with the string `ex'. It is also possible to say `%?string' which specifies a job whose text contains string, if there is only one such job.
The shell maintains a notion of the current and previous jobs.
In output pertaining to jobs, the current job is marked with a `+'
and the previous job with a `-'. The abbreviation `%+' refers
to the current job and `%-' refers to the previous job. For close
analogy with the syntax of the
history
mechanism (described below),
`%%' is also a synonym for the current job.
Status reporting
This shell learns immediately whenever a process changes state. It normally informs you whenever a job becomes blocked so that no further progress is possible, but only just before it prints a prompt. This is done so that it does not otherwise disturb your work. If, however, you set the shell variable notify, the shell will notify you immediately of changes of status in background jobs. There is also a shell command notify which marks a single process so that its status changes will be immediately reported. By default notify marks the current process; simply say `notify' after starting a background job to mark it.
When you try to leave the shell while jobs are stopped, you will
be warned that `You have stopped jobs.' You may use the jobs
command to see what they are. If you do this or immediately try to
exit again, the shell will not warn you a second time, and the suspended
jobs will be terminated.
File Name Completion
When the file name completion feature is enabled by setting the shell variable filec (see set), csh will interactively complete file names and user names from unique prefixes, when they are input from the terminal followed by the escape character (the escape key, or control-[). For example, if the current directory looks like
DSC.OLD bin cmd lib xmpl.c DSC.NEW chaosnet cmtest mail xmpl.o bench class dev mbox xmpl.outand the input is
If a partial file name is followed by the end-of-file character
(usually control-D), then, instead of completing the name, csh
will list all file names matching the prefix. For example,
the input
% vi D<control-D>
causes all files beginning with ``D'' to be listed:
DSC.NEW DSC.OLD
while the input line remains unchanged.
The same system of escape and end-of-file can also be used to
expand partial user names, if the word to be completed
(or listed) begins with the character ``~''. For example,
typing
cd ~ro<control-D>
may produce the expansion
cd ~root
The use of the terminal bell to signal errors or multiple matches can be inhibited by setting the variable nobeep.
Normally, all files in the particular directory are candidates
for name completion. Files with certain suffixes can be excluded
from consideration by setting the variable fignore to the
list of suffixes to be ignored. Thus, if fignore is set by
the command
% set fignore = (.o .out)
then typing
% vi x<escape>
would result in the completion to
% vi xmpl.c
ignoring the files "xmpl.o" and "xmpl.out".
However, if the only completion possible requires not ignoring these
suffixes, then they are not ignored. In addition, fignore
does not affect the listing of file names by control-D. All files
are listed regardless of their suffixes.
Substitutions
We now describe the various transformations the shell performs on the
input in the order in which they occur.
History substitutions
History substitutions place words from previous command input as portions of new commands, 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 `!' and may begin anywhere in the input stream (with the proviso that they do not nest.) This `!' may be preceded by an `\' 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.) Any input line which contains history substitution is echoed on the terminal before it is executed as it could have been typed without history substitution.
Commands input from the terminal which consist of one or more words are saved on the history list. The history substitutions reintroduce sequences of words from these saved commands into the input stream. The size of which is controlled by the history variable; the previous command is always retained, regardless of its value. Commands are numbered sequentially from 1.
For definiteness, consider the following output from the history command:
9 write michael
10 ex write.c
11 cat oldwrite.c
12 diff *write.c
The commands are shown with their event numbers. 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 string.
With the current event 13 we can refer to previous events by event number `!11', relatively as in `!-2' (referring to the same event), by a prefix of a command word as in `!d' for event 12 or `!wri' for event 9, or by a string contained in a word in the command as in `!?mic?' also referring to event 9. These forms, without further modification, simply reintroduce the words of the specified events, each separated by a single blank. As a special case `!!' refers to the previous command; thus `!!' alone is essentially a redo.
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:
0 first (command) word n n'th argument ^ first argument, i.e. `1' $ last argument % word matched by (immediately preceding) ?s? search x-y range of words -y abbreviates `0-y' * abbreviates `^-$', or nothing if only 1 word in event x* abbreviates `x-$' x- like `x*' but omitting word `$'
The `:' separating the event specification from the word designator can be omitted if the argument selector begins with a `^', `$', `*' `-' or `%'. After the optional word designator can be placed a sequence of modifiers, each preceded by a `:'. The following modifiers are defined:
h Remove a trailing pathname component, leaving the head. r Remove a trailing `.xxx' component, leaving the root name. e Remove all but the extension `.xxx' part. s/l/r/ Substitute l for r t Remove all leading pathname components, leaving the tail. & Repeat the previous substitution. g Apply the change globally, prefixing the above, e.g. `g&'. p Print the new command but do not execute it. q Quote the substituted words, preventing further substitutions. x Like q, but break into words at blanks, tabs and newlines.
Unless preceded by a `g' the modification is applied only to the first modifiable word. With substitutions, it is an error for no word to be applicable.
The left hand side of substitutions are not regular expressions in the sense of the editors, but rather strings. Any character may be used as the delimiter in place of `/'; a `\' quotes the delimiter into the l and r strings. The character `&' in the right hand side is replaced by the text from the left. A `\' quotes `&' also. A null l uses the previous string either from a l or from a contextual scan string s in `!?s?'. The trailing delimiter in the substitution may be omitted if a newline follows immediately as may the trailing `?' in a contextual scan.
A history reference may be given without an event specification, e.g. `!$'. In this case the reference is to the previous command unless a previous history reference occurred on the same line in which case this form repeats the previous reference. Thus `!?foo?^ !$' gives the first and last arguments from the command matching `?foo?'.
A special abbreviation of a history reference occurs when the first non-blank character of an input line is a `^'. This is equivalent to `!:s^' providing a convenient shorthand for substitutions on the text of the previous line. Thus `^lb^lib' fixes the spelling of `lib' in the previous command. Finally, a history substitution may be surrounded with `{' and `}' if necessary to insulate it from the characters which follow. Thus, after `ls -ld ~paul' we might do `!{l}a' to do `ls -ld ~paula', while `!la' would look for a command starting `la'.
Quotations with ' and "
The quotation of strings by `'' and `"' can be used to prevent all or some of the remaining substitutions. Strings enclosed in `'' are prevented any further interpretation. Strings enclosed in `"' may be expanded as described below.
In both cases the resulting text becomes (all or part of) a single word;
only in one special case (see
Command Substitition
below) does a `"' quoted string yield parts of more than one word;
`'' quoted strings never do.
Alias substitution
The shell maintains a list of aliases which can be established, displayed and modified by the alias and unalias commands. After a command line is scanned, it is parsed into distinct commands and the first word of each command, left-to-right, is checked to see if it has an alias. If it does, then the text which is the alias for that command is reread with the history mechanism available as though that command were the previous input line. The resulting words replace the command and argument list. If no reference is made to the history list, then the argument list is left unchanged.
Thus if the alias for `ls' is `ls -l' the command `ls /usr' would map to `ls -l /usr', the argument list here being undisturbed. Similarly if the alias for `lookup' was `grep !^ /etc/passwd' then `lookup bill' would map to `grep bill /etc/passwd'.
If an alias is found, the word transformation of the input text is performed and the aliasing process begins again on the reformed input line. Looping is prevented if the first word of the new text is the same as the old by flagging it to prevent further aliasing. Other loops are detected and cause an error.
Note that the mechanism allows aliases to introduce parser metasyntax.
Thus we can `alias print 'pr \!* | lpr'' to make a command which
pr's
its arguments to the line printer.
Variable substitution
The shell maintains a set of variables, each of which has as value a list of zero or more words. Some of these variables are set by the shell or referred to by it. For instance, the argv variable is an image of the shell's argument list, and words of this variable's value are referred to in special ways.
The values of variables may be displayed and changed by using the set and unset commands. Of the variables referred to by the shell a number are toggles; the shell does not care what their value is, only whether they are set or not. For instance, the verbose variable is a toggle which causes command input to be echoed. The setting of this variable results from the -v command line option.
Other operations treat variables numerically. The `@' command permits numeric calculations to be performed and the result assigned to a variable. Variable values are, however, always represented as (zero or more) strings. For the purposes of numeric operations, the null string is considered to be zero, and the second and subsequent words of multiword values are ignored.
After the input line is aliased and parsed, and before each command is executed, variable substitution is performed keyed by `$' characters. This expansion can be prevented by preceding the `$' with a `\' except within `"'s where it always occurs, and within `''s where it never occurs. Strings quoted by ``' are interpreted later (see Command substitution below) so `$' substitution does not occur there until later, if at all. A `$' is passed unchanged if followed by a blank, tab, or end-of-line.
Input/output redirections are recognized before variable expansion, and are variable expanded separately. Otherwise, the command name and entire argument list are expanded together. It is thus possible for the first (command) word to this point to generate more than one word, the first of which becomes the command name, and the rest of which become arguments.
Unless enclosed in `"' or given the `:q' modifier the results of variable substitution may eventually be command and filename substituted. Within `"', a variable whose value consists of multiple words expands to a (portion of) a single word, with the words of the variables value separated by blanks. When the `:q' modifier is applied to a substitution the variable will expand to multiple words with each word separated by a blank and quoted to prevent later command or filename substitution.
The following metasequences are provided for introducing variable values into the shell input. Except as noted, it is an error to reference a variable which is not set.
The modifiers `:h', `:t', `:r', `:q' and `:x' may be applied to the substitutions above as may `:gh', `:gt' and `:gr'. If braces `{' '}' appear in the command form then the modifiers must appear within the braces. The current implementation allows only one `:' modifier on each `$' expansion.
The following substitutions may not be modified with `:' modifiers.
Command and filename substitution
The remaining substitutions, command and filename substitution,
are applied selectively to the arguments of builtin commands.
This means that portions of expressions which are not evaluated are
not subjected to these expansions.
For commands which are not internal to the shell, the command
name is substituted separately from the argument list.
This occurs very late,
after input-output redirection is performed, and in a child
of the main shell.
Command substitution
Command substitution is indicated by a command enclosed in ``'. The output from such a command is normally broken into separate words at blanks, tabs and newlines, with null words being discarded, this text then replacing the original string. Within `"'s, only newlines force new words; blanks and tabs are preserved.
In any case, the single final newline does not force a new word.
Note that it is thus possible for a command substitution to yield
only part of a word, even if the command outputs a complete line.
Filename substitution
If a word contains any of the characters `*', `?', `[' or `{' or begins with the character `~', then that word is a candidate for filename substitution, also known as `globbing'. This word is then regarded as a pattern, and replaced with an alphabetically sorted list of file names which match the pattern. In a list of words specifying filename substitution it is an error for no pattern to match an existing file name, but it is not required for each pattern to match. Only the metacharacters `*', `?' and `[' imply pattern matching, the characters `~' and `{' being more akin to abbreviations.
In matching filenames, the character `.' at the beginning of a filename or immediately following a `/', as well as the character `/' must be matched explicitly. The character `*' matches any string of characters, including the null string. The character `?' matches any single character. The sequence `[...]' matches any one of the characters enclosed. Within `[...]', a pair of characters separated by `-' matches any character lexically between the two.
The character `~' at the beginning of a filename is used to refer to home directories. Standing alone, i.e. `~' it expands to the invokers home directory as reflected in the value of the variable home. When followed by a name consisting of letters, digits and `-' characters the shell searches for a user with that name and substitutes their home directory; thus `~ken' might expand to `/usr/ken' and `~ken/chmach' to `/usr/ken/chmach'. If the character `~' is followed by a character other than a letter or `/' or appears not at the beginning of a word, it is left undisturbed.
The metanotation `a{b,c,d}e' is a shorthand for `abe ace ade'.
Left to right order is preserved, with results of matches being sorted
separately at a low level to preserve this order.
This construct may be nested.
Thus `~source/s1/{oldls,ls}.c' expands to
`/usr/source/s1/oldls.c /usr/source/s1/ls.c'
whether or not these files exist without any chance of error
if the home directory for `source' is `/usr/source'.
Similarly `../{memo,*box}' might expand to `../memo ../box ../mbox'.
(Note that `memo' was not sorted with the results of matching `*box'.)
As a special case `{', `}' and `{}' are passed undisturbed.
Input/output
The standard input and standard output of a command may be redirected with the following syntax:
A command receives the environment in which the shell was invoked as modified by the input-output parameters and the presence of the command in a pipeline. Thus, unlike some previous shells, commands run from a file of shell commands have no access to the text of the commands by default; rather they receive the original standard input of the shell. The `<<' mechanism should be used to present inline data. This permits shell command scripts to function as components of pipelines and allows the shell to block read its input. Note that the default standard input for a command run detached is not modified to be the empty file `/dev/null'; rather the standard input remains as the original standard input of the shell. If this is a terminal and if the process attempts to read from the terminal, then the process will block and the user will be notified (see Jobs above).
Diagnostic output may be directed through a pipe with the standard output.
Simply use the form `|&' rather than just `|'.
Expressions
A number of the builtin commands (to be described subsequently) take expressions, in which the operators are similar to those of C, with the same precedence. These expressions appear in the @, exit, if, and while commands. The following operators are available:
|| && | ^ & == != =~ !~ <= >= < > << >> + - * / % ! ~ ( )
Here the precedence increases to the right, `==' `!=' `=~' and `!~', `<=' `>=' `<' and `>', `<<' and `>>', `+' and `-', `*' `/' and `%' being, in groups, at the same level. The `==' `!=' `=~' and `!~' operators compare their arguments as strings; all others operate on numbers. The operators `=~' and `!~' are like `!=' and `==' except that the right hand side is a pattern (containing, e.g. `*'s, `?'s and instances of `[...]') against which the left hand operand is matched. This reduces the need for use of the switch statement in shell scripts when all that is really needed is pattern matching.
Strings which begin with `0' are considered octal numbers. Null or missing arguments are considered `0'. The result of all expressions are strings, which represent decimal numbers. It is important to note that no two components of an expression can appear in the same word; except when adjacent to components of expressions which are syntactically significant to the parser (`&' `|' `<' `>' `(' `)') they should be surrounded by spaces.
Also available in expressions as primitive operands are command executions enclosed in `{' and `}' and file enquiries of the form `-l name' where l is one of:
r read access w write access x execute access e existence o ownership z zero size f plain file d directory
The specified name is command and filename expanded and then tested
to see if it has the specified relationship to the real user.
If the file does not exist or is inaccessible then all enquiries return
false, i.e. `0'.
Command executions succeed, returning true, i.e. `1',
if the command exits with status 0, otherwise they fail, returning
false, i.e. `0'.
If more detailed status information is required then the command
should be executed outside of an expression and the variable
status
examined.
Control flow
The shell contains a number of commands which can be used to regulate the flow of control in command files (shell scripts) and (in limited but useful ways) from terminal input. These commands all operate by forcing the shell to reread or skip in its input and, due to the implementation, restrict the placement of some of the commands.
The foreach, switch, and while statements, as well as the if-then-else form of the if statement require that the major keywords appear in a single simple command on an input line as shown below.
If the shell's input is not seekable,
the shell buffers up input whenever a loop is being read
and performs seeks in this internal buffer to accomplish the rereading
implied by the loop.
(To the extent that this allows, backward goto's will succeed on
non-seekable inputs.)
Builtin commands
Builtin commands are executed within the shell. If a builtin command occurs as any component of a pipeline except the last then it is executed in a subshell.
Pre-defined and environment variables
The following variables have special meaning to the shell. Of these, argv, cwd, home, path, prompt, shell and status are always set by the shell. Except for cwd and status this setting occurs only at initialization; these variables will not then be modified unless this is done explicitly by the user.
This shell copies the environment variable USER into the variable user, TERM into term, and HOME into home, and copies these back into the environment whenever the normal shell variables are reset. The environment variable PATH is likewise handled; it is not necessary to worry about its setting other than in the file .cshrc as inferior csh processes will import the definition of path from the environment, and re-export it if you then change it.
Non-builtin command execution
When a command to be executed is found to not be a builtin command the shell attempts to execute the command via execve(2). Each word in the variable path names a directory from which the shell will attempt to execute the command. If it is given neither a -c nor a -t option, the shell will hash the names in these directories into an internal table so that it will only try an exec in a directory if there is a possibility that the command resides there. This greatly speeds command location when a large number of directories are present in the search path. If this mechanism has been turned off (via unhash), or if the shell was given a -c or -t argument, and in any case for each directory component of path which does not begin with a `/', the shell concatenates with the given command name to form a path name of a file which it then attempts to execute.
Parenthesized commands are always executed in a subshell. Thus `(cd ; pwd) ; pwd' prints the home directory; leaving you where you were (printing this after the home directory), while `cd ; pwd' leaves you in the home directory. Parenthesized commands are most often used to prevent chdir from affecting the current shell.
If the file has execute permissions but is not an executable binary to the system, then it is assumed to be a file containing shell commands and a new shell is spawned to read it.
If there is an
alias
for
shell
then the words of the alias will be prepended to the argument list to form
the shell command.
The first word of the
alias
should be the full path name of the shell
(e.g. `$shell').
Note that this is a special, late occurring, case of
alias
substitution,
and only allows words to be prepended to the argument list without modification.
Argument list processing
If argument 0 to the shell is `-' then this is a login shell. 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 was given, the first argument is taken as the name of a file of
commands to be executed.
The shell opens this file, and saves its name for possible resubstitution
by `$0'.
Since many systems use either the standard version 6 or version 7 shells
whose shell scripts are not compatible with this shell, the shell will
execute such a `standard' shell if the first character of a script
is not a `#', i.e. if the script does not start with a comment.
Remaining arguments initialize the variable
argv.
Signal handling
The shell normally ignores quit signals. Jobs running detached (either by `&' or the bg or %... & commands) are immune to signals generated from the keyboard, including hangups. Other signals have the values which the shell inherited from its parent. The shells handling of interrupts and terminate signals in shell scripts can be controlled by onintr. Login shells catch the terminate signal; otherwise this signal is passed on to children from the state in the shell's parent. In no case are interrupts allowed when a login shell is reading the file `.logout'.
The shell's editing mode is determined by the value of the shell editmode variable which users should set to emacs in their .cshrc files If editmode is not set, then the shell will run in "dumb" mode. It is possible to set the mode after the shell starts up; so if you find yourself in "dumb" mode, you can alter the situation without having to log out and log in again. Setting the editmode variable has two important side effects: (1) it causes the key bindings to be reevaluated, and (2) it sets the EDITMODE environment variable. The latter has no effect within the shell; so users should not set the environment variable directly in hopes of altering the editing mode.
Terminal control capabilities are extracted from the user's termcap file (usually /etc/termcap), using the value of the shell variable term -- not the environment variable TERM -- as the terminal type. If term is undefined, unknown, or if the associated termcap definition is inadequate, a warning will be displayed and most, or all, of the editing features of the shell will be disabled. It is the user's responsibility to make sure that term is set to an appropriate value before the editmode variable is set to emacs. Usually this should be done in the .cshrc file. If editing is disabled because term is not properly set when the shell starts up, simply setting term to the proper value will normally cause the shell editor to be re-enabled. NB: Setting the shell variable term causes the environment variable TERM to be set to the same value. For information on controlling the bell, see the DIAGNOSTICS section.
There is a new command in this shell, bind-to-key, which allows the functions listed in the BINDINGS section below, and also user defined keyboard macros, to be bound to keys. The form of the command is
bind-to-key
function key ...
where function is one of the function names from the list or else the single character name of a keyboard macro and where key is a quoted string designating a key sequence. Control characters in the key designation should not be entered literally, but should be indicated by the prefix "\^", e.g. "\^X". Similarly, escape is indicated by "\e". A literal slash is "\\". Escape and control-X are the only legitimate "prefix" characters. The following mnemonics should be used: "\t" for tab, "\^?" for rubout, "\n" for newline, and "\r" for return. Since the shell converts returns to newlines it is probably unwise to alter the binding of newline.
During editor initialization the shell will read a file named .bindings in the user's home directory. If you regularly want certain non-default key bindings to be effective, put the appropriate bind-to-key commands in your ~/.bindings file. NB: The bind-to-key commands would work if placed in your ~/.cshrc file, but they will be more useful (in the future) if they are in the ~/.bindings file.
Invocation of the history mechanism with "!" either causes the matched command to be inserted on the command line for editing before execution or immediatedly executes the command. This is controlled by the shell variable edithist, which is automatically set, when the shell variable editmode is set, thereby allowing editing of previous commands invoked by the history mechanism. This feature may be turned off with the command "unset edithist", which may be placed in the user's .cshrc file.
in the
.cshrc
file in
your home directory.
If you don't have such a file, create one
and add the line to the end.
Log out and log in again and you will be using the new shell.
Emacs Function Name Remark ^B Backspace ESC-b BackwardWord ^A BeginningOfLine ^L ClearScreen DefaultBinding ESC-n DefineNamedMacro name macro ^D DeleteCurrentChar ^H DeletePreviousChar ESC-d DeleteWord after cursor EndOfFile exit shell ^E EndOfLine EraseLine kills whole line ESC-h EraseWord before cursor ESC-e ExecuteNamedMacro ESC-x ExecuteNamedMacro ^X-e ExecuteUnNamedMacro ESC-ESC FilenameExpansion ESC-l FilenameList ^F ForwardChar ESC-f ForwardWord ^W KillRegion to kill buffer ^K KillToEOL to kill buffer IncrementalSearchForward IncrementalSearchReverse InsertChar self insert ^V InsertLiteralChar ^X^R LoadMacroFile ^N NextHistEntry wraps around ^P PreviousHistEntry wraps around ^R Redisplay redraws line ^U Repetition greater than 0 ^M,^J Return ^X^S SaveMacroFile ^@ SetMark default mark at BOL SearchReverse look for next char SearchForward look for next char ^Q StartFlow (see FLOW CONTROL) ^X-( StartRemembering begin a macro ^S StopFlow (see FLOW CONTROL) ^X-) StopRemembering end a macro ^I Tab inserts 8 spaces ^T TransposeChars before cursor ^Y YankKillBuffer no kill ring
Users may change the bindings of functions to keys by means of the shell bind-to-key command. These commands may be stored in a file named .bindings in the users home directory and will then be read by the shell when the editor is initialized.
NB: The shell variable bindings is no longer being supported and will become ineffective in a future release. Before that happens users should convert to using the ~/.bindings file.
The functions StopFlow and StartFlow can only be usefully bound to the keys that the terminal driver interprets as performing the corresponding flow control functions. In other words, you cannot simply bind these functions to other keys in order to have them perform the flow control operations normally provided by ^S and ^Q.
Notice that this is a multi-line macro, since it contains an embedded newline. The user can give this macro a single character name, e.g. "e", as follows:
% \ene (escape-n-e).
The macro may then be executed by typing "\exe". It can also be bound to a key using the bind-to-key command. Macros can be saved in files and can be reloaded automatically when the shell starts up.
NB: It is not advisable to try to edit saved macros!
Four search functions are available to the user, but are not bound (by default) to keys. If you want to use them, use the cshell bind-to-key command to bind them to keys.
~/.cshrc Read at beginning of execution by each shell. ~/.login Read by login shell, after `.cshrc' at login. ~/.logout Read by login shell, at logout. ~/.bindings Definitions for non-default key bindings, read during shell editor initialization. /bin/sh Standard shell, for shell scripts not starting with a `#'. /tmp/sh* Temporary file for `<<'. /etc/passwd Source of home directories for `~name'.
Shell builtin functions are not stoppable/restartable. Command sequences of the form `a ; b ; c' are also not handled gracefully when stopping is attempted. If you suspend `b', the shell will then immediately execute `c'. This is especially noticeable if this expansion results from an alias. It suffices to place the sequence of commands in ()'s to force it to a subshell, i.e. `( a ; b ; c )'.
Control over tty output after processes are started is primitive; perhaps this will inspire someone to work on a good virtual terminal interface. In a virtual terminal interface much more interesting things could be done with output control.
Alias substitution is most often used to clumsily simulate shell procedures; shell procedures should be provided rather than aliases.
Commands within loops, prompted for by `?', are not placed in the history list. Control structure should be parsed rather than being recognized as built-in commands. This would allow control commands to be placed anywhere, to be combined with `|', and to be used with `&' and `;' metasyntax.
It should be possible to use the `:' modifiers on the output of command substitutions. All and more than one `:' modifier should be allowed on `$' substitutions.
The shell variable filec is currently ignored; this means that file and user name completion always takes place. Also, the way the filec facility is implemented is ugly and expensive.