# Redirection \Fix me: To be continued\\ Redirection makes it possible to control where the output of a command goes to, and where the input of a command comes from. It\'s a mighty tool that, together with pipelines, makes the shell powerful. The redirection operators are checked whenever a [simple command is about to be executed](/syntax/grammar/parser_exec). Under normal circumstances, there are 3 files open, accessible by the file descriptors 0, 1 and 2, all connected to your terminal: Name FD Description ---------- ---- -------------------------------------------------------- `stdin` 0 standard input stream (e.g. keyboard) `stdout` 1 standard output stream (e.g. monitor) `stderr` 2 standard error output stream (usually also on monitor) \The terms \"monitor\" and \"keyboard\" refer to the same device, the **terminal** here. Check your preferred UNIX(r)-FAQ for details, I\'m too lazy to explain what a terminal is ;-) \ Both, `stdout` and `stderr` are output file descriptors. Their difference is the **convention** that a program outputs payload on `stdout` and diagnostic- and error-messages on `stderr`. If you write a script that outputs error messages, please make sure you follow this convention! Whenever you **name** such a filedescriptor, i.e. you want to redirect this descriptor, you just use the number: # this executes the cat-command and redirects its error messages (stderr) to the bit bucket cat some_file.txt 2>/dev/null Whenever you **reference** a descriptor, to point to its current target file, then you use a \"`&`\" followed by a the descriptor number: # this executes the echo-command and redirects its normal output (stdout) to the standard error target echo "There was an error" 1>&2 The redirection operation can be **anywhere** in a simple command, so these examples are equivalent: cat foo.txt bar.txt >new.txt cat >new.txt foo.txt bar.txt >new.txt cat foo.txt bar.txt \Every redirection operator takes one or two words as operands. If you have to use operands (e.g. filenames to redirect to) that contain spaces you **must** quote them!\ ## Valid redirection targets and sources This syntax is recognized whenever a `TARGET` or a `SOURCE` specification (like below in the details descriptions) is used. Syntax Description ---------------------- -------------------------------------------------------------------------------------------------------------------------------------------------------- `FILENAME` references a normal, ordinary filename from the filesystem (which can of course be a FIFO, too. Simply everything you can reference in the filesystem) `&N` references the current target/source of the filedescriptor `N` (\"duplicates\" the filedescriptor) `&-` closes the redirected filedescriptor, useful instead of `> /dev/null` constructs (`> &-`) `/dev/fd/N` duplicates the filedescriptor `N`, if `N` is a valid integer `/dev/stdin` duplicates filedescriptor 0 (`stdin`) `/dev/stdout` duplicates filedescriptor 1 (`stdout`) `/dev/stderr` duplicates filedescriptor 2 (`stderr`) `/dev/tcp/HOST/PORT` assuming `HOST` is a valid hostname or IP address, and `PORT` is a valid port number or service name: redirect from/to the corresponding TCP socket `/dev/udp/HOST/PORT` assuming `HOST` is a valid hostname or IP address, and `PORT` is a valid port number or service name: redirect from/to the corresponding UDP socket If a target/source specification fails to open, the whole redirection operation fails. Avoid referencing file descriptors above 9, since you may collide with file descriptors Bash uses internally. ## Redirecting output N > TARGET This redirects the file descriptor number `N` to the target `TARGET`. If `N` is omitted, `stdout` is assumed (FD 1). The `TARGET` is **truncated** before writing starts. If the option `noclobber` is set with [the set builtin](/commands/builtin/set), with cause the redirection to fail, when `TARGET` names a regular file that already exists. You can manually override that behaviour by forcing overwrite with the redirection operator `>|` instead of `>`. ## Appending redirected output N >> TARGET This redirects the file descriptor number `N` to the target `TARGET`. If `N` is omitted, `stdout` is assumed (FD 1). The `TARGET` is **not truncated** before writing starts. ## Redirecting output and error output &> TARGET >& TARGET This special syntax redirects both, `stdout` and `stderr` to the specified target. It\'s **equivalent** to > TARGET 2>&1 Since Bash4, there\'s `&>>TARGET`, which is equivalent to `>> TARGET 2>&1`. \This syntax is deprecated and should not be used. See the page about [obsolete and deprecated syntax](/scripting/obsolete).\ ## Appending redirected output and error output To append the cumulative redirection of `stdout` and `stderr` to a file you simply do >> FILE 2>&1 &>> FILE ## Transporting stdout and stderr through a pipe COMMAND1 2>&1 | COMMAND2 COMMAND1 |& COMMAND2 ## Redirecting input N < SOURCE The input descriptor `N` uses `SOURCE` as its data source. If `N` is omitted, filedescriptor 0 (`stdin`) is assumed. ## Here documents \ <It seems that here-documents (tested on versions `1.14.7`, `2.05b` and `3.1.17`) are correctly terminated when there is an EOF before the end-of-here-document tag. The reason is unknown, but it seems to be done on purpose. Bash 4 introduced a warning message when end-of-file is seen before the tag is reached.\ ## Here strings <<< WORD The here-strings are a variation of the here-documents. The word `WORD` is taken for the input redirection: cat <<< "Hello world... $NAME is here..." Just beware to quote the `WORD` if it contains spaces. Otherwise the rest will be given as normal parameters. The here-string will append a newline (`\n`) to the data. ## Multiple redirections More redirection operations can occur in a line of course. The order is **important**! They\'re evaluated from **left to right**. If you want to redirect both, `stderr` and `stdout` to the same file (like `/dev/null`, to hide it), this is **the wrong way**: ``` bash # { echo OUTPUT; echo ERRORS >&2; } is to simulate something that outputs to STDOUT and STDERR # you can test with it { echo OUTPUT; echo ERRORS >&2; } 2>&1 1>/dev/null ``` Why? Relatively easy: - initially, `stdout` points to your terminal (you read it) - same applies to `stderr`, it\'s connected to your terminal - `2>&1` redirects `stderr` away from the terminal to the target for `stdout`: **the terminal** (again\...) - `1>/dev/null` redirects `stdout` away from your terminal to the file `/dev/null` What remains? `stdout` goes to `/dev/null`, `stderr` still (or better: \"again\") goes to the terminal. You have to swap the order to make it do what you want: ``` bash { echo OUTPUT; echo ERRORS >&2; } 1>/dev/null 2>&1 ``` ## Examples How to make a program quiet (assuming all output goes to `STDOUT` and `STDERR`? command >/dev/null 2>&1 ## See also - Internal: [Illustrated Redirection Tutorial](/howto/redirection_tutorial) - Internal: [The noclobber option](/commands/builtin/set#tag_noclobber) - Internal: [The exec builtin command](/commands/builtin/exec) - Internal: [Simple commands parsing and execution](/syntax/grammar/parser_exec) - Internal: [Process substitution syntax](/syntax/expansion/proc_subst) - Internal: [Obsolete and deprecated syntax](/scripting/obsolete) - Internal: [Nonportable syntax and command uses](/scripting/nonportable)