What is tcsh in linux

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:

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:

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

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,

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:

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:

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

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:

• 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:

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 !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 !* .

Источник