Redirection (computing)
In computing, redirection is a form of interprocess communication, and is a function common to most command-line interpreters, including the various Unix shells that can redirect standard streams to user-specified locations. In Unix-like operating systems, programs do redirection with the system call, or its less-flexible but higher-level stdio analogues, and . Redirecting standard input and standard output. Redirection is usually implemented by placing certain characters between commands. Basic. Typically, the syntax of these characters is as follows, using codice_1 to redirect input, and codice_2 to redirect output. command > file1 executes , placing the output  in , as opposed to displaying it at the terminal, which is the usual destination for standard output. This will clobber any existing data in . Using command < file1 executes , with as the source of input, as opposed to the keyboard, which is the usual source for standard input. command < infile > outfile combines the two capabilities: reads from and writes to Variants. To append output to the end of the file, rather than clobbering it, the codice_3 operator is used: command1 » file1. To read from a stream literal (an inline file, passed to the standard input), one can use  a here document, using the codice_4 operator: $ tr a-z A-Z « END_TEXT > one two three > uno dos tres > END_TEXT ONE TWO THREE UNO DOS TRES To read from a string, one can use a here string, using the codice_5 operator: tr a-z A-Z «< "one two three", or: $ NUMBERS="one two three" $ tr a-z A-Z «< "$NUMBERS" ONE TWO THREE Piping. Programs can be run together such that one program reads the output from another with no need for an explicit intermediate file. command1 | command2 executes , using its  output as the input for (commonly called piping, with the "codice_6" character being known as the "pipe"). The two programs performing the commands may run in parallel with the only storage space being working buffers (Linux allows up to 64K for each buffer) plus whatever work space each command's processing requires. For example, a "sort" command is unable to produce any output until all input records have been read, as the very last record received just might turn out to be first in sorted order. Dr. Alexia Massalin's experimental operating system, Synthesis, would adjust the priority of  each task as they ran according to the fullness of their input and output buffers. This produces the same end result as using two redirects and a temporary file, as in: $ command1 > tempfile $ command2 < tempfile $ rm tempfile But here, does not start executing until has finished, and a sufficiently large scratch file is required to hold the intermediate results as well as whatever work space each task required. As an example, although DOS allows the "pipe" syntax, it employs this second approach. Thus, suppose some long-running program "Worker" produces various messages as it works , and that a second program, TimeStamp copies each record from "stdin" to "stdout", prefixed by the system's date and time when the record is received. A sequence such as Worker | TimeStamp > LogFile.txt would produce timestamps only when Worker had finished, merely showing how swiftly its output file could be read and written. A good example for command piping is combining codice_7 with another command to achieve something interactive in a non-interactive shell, e.g. echo -e 'user\npass' | ftp localhost. This runs the ftp client with input , press , then . In casual use, the initial step of a  pipeline is often codice_8 or codice_7, reading from a file or string. This can often be replaced by input indirection or a here string, and use of cat and piping rather than input redirection is known as useless use of cat. For example, the following commands: $ cat infile | command $ echo $string | command $ echo -e 'user\npass' | ftp localhost can be replaced by: $ command < infile $ command «< $string $ ftp localhost «< $'user\npass' As codice_7 is often a shell-internal command, its use is not as criticized as cat, which  is an external command. Redirecting to and from the standard file handles. In Unix shells derived from the original Bourne shell, the first two actions can be further modified by placing a number (the file descriptor) immediately before the character; this will affect which stream is used for the redirection. The Unix standard I/O streams are: For example, executes , directing the standard error stream to . In shells derived from csh (the C shell), the syntax instead appends the (ampersand) character to the redirect characters, thus achieving a similar result. The reason for this is to distinguish between a file  named '1' and stdout, i.e. vs . In the first case, stderr is redirected to a file named " and in the second, stderr is redirected to stdout. Another useful capability is to redirect one standard file handle to another. The most popular variation is to merge standard error into standard output so error messages can be processed together with (or alternately to) the usual output. For example, will try to find all files named . Executed without redirection, it will output hits to stdout and errors (e.g. for lack of privilege to traverse protected directories) to stderr. If standard output is directed  to file , error messages appear on the console. To see both hits and error messages in file , merge stderr (handle 2) into stdout (handle 1) using . If the merged output is to be piped into another program, the file merge sequence must precede the pipe symbol, thus, A simplified but non-POSIX conforming form of the command, is (not available in Bourne Shell prior to version 4, final release, or in the standard shell Debian Almquist shell used in Debian/Ubuntu): or . It is possible to use codice_11 before "codice_2" but the result is commonly misunderstood. The rule is that  any redirection sets the handle to the output stream independently. So "codice_11" sets handle codice_14 to whatever handle codice_15 points to, which at that point usually is "stdout". Then "codice_2" redirects handle codice_15 to something else, e.g. a file, but it does not change handle codice_14, which still points to "stdout". In the following example, standard output is written to "file", but errors are redirected from stderr to stdout, i.e. sent to the screen: . To write both errors and standard output to "file", the order should be reversed. Standard output would first be redirected to the file, then stderr would  additionally be redirected to the stdout handle that has already been changed to point at the file: . Chained pipelines. The redirection and piping tokens can be chained together to create complex commands. For example, sort infile | uniq -c | sort -n > outfile sorts the lines of in lexicographical order, writes unique lines prefixed by the number of occurrences, sorts the resultant output numerically, and places the final output in . This type of construction is used very commonly in shell scripts and batch files. Redirect to multiple outputs. The standard command can redirect output from a command to several  destinations:ls -lrt | tee xyz. This directs the file list output to both standard output and the file .