Content deleted Content added
→Sources: +1 |
|||
| (35 intermediate revisions by 20 users not shown) | |||
Line 1:
{{More citations needed|date=April 2024}}
<!-- Note: The following pages were redirects to [[Redirection (computing)]] before draftification:
*[[Redirection operator]]
*[[Redirection (Unix)]]
*[[Redirect (computing)]]
-->
{{Short description|Form of interprocess communication}}
{{distinguish|URL redirection}}
[[Image:Stdstreams-notitle.svg|thumb|300px|The standard streams for input, output, and error]]
In [[computing]], '''redirection''' is a form of [[interprocess communication]], and is a function common to most [[command-line interpreter]]s, including the various [[Unix shell]]s that can redirect [[standard streams]] to user-specified locations. The concept of redirection is quite old, dating back to the earliest operating systems (OS).{{cn|date=April 2024}} A discussion of the design goals for redirection can be found already in the 1971 description of the [[input-output]] subsystem of the [[Multics]] OS.{{sfn | Feiertag | Organick | 1972 | p=}} However, prior to the introduction of [[UNIX]] OS with its "[[Pipeline (Unix)|pipes]]", redirection in operating systems was hard or even impossible to do.{{sfn | Kernighan | Morgan | 1982 | p=780 | loc=Input/output redirection}}
In [[Unix-like]] operating systems, programs do redirection with the {{mono|[[dup2]](2)}} [[system call]], or its less-flexible but higher-level [[Standard streams|stdio]] analogues, {{mono|[[freopen]](3)}} and {{mono|[[popen]](3)}}.<ref>[https://www.gnu.org/software/libc/manual/html_mono/libc.html The GNU C Library Reference Manual for version 2.38] gnu.org</ref>
==Redirecting standard input and standard output==
Line 11 ⟶ 17:
===Basic===
Typically, the [[syntax]] of these characters is as follows, using <code><</code> to redirect input, and <code>></code> to redirect output. <syntaxhighlight lang="bash" inline>
Using <syntaxhighlight lang="bash" inline>
<syntaxhighlight lang="bash" inline>
===Variants===
Line 21 ⟶ 27:
To read from a stream literal (an inline file, passed to the standard input), one can use a [[here document]], using the <code><<</code> operator:
<syntaxhighlight lang="
$ tr a-z A-Z << END_TEXT
> one two three
> uno dos tres
> END_TEXT
ONE TWO THREE
UNO DOS TRES
</syntaxhighlight>
To read from a string, one can use a [[here string]], using the <code><<<</code> operator: <syntaxhighlight lang="bash" inline>tr a-z A-Z <<< "one two three"</syntaxhighlight>, or:
<syntaxhighlight lang="
$ NUMBERS="one two three"
$ tr a-z A-Z <<< "$NUMBERS"
ONE TWO THREE
</syntaxhighlight>
Line 39 ⟶ 48:
Programs can be run together such that one program reads the output from another with no need for an explicit intermediate file. <syntaxhighlight lang="bash" inline>command1 | command2</syntaxhighlight> executes {{mono|command1}}, using its output as the input for {{mono|command2}} (commonly called [[Pipeline (Unix)|piping]], with the "<code>|</code>" 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 kernel#Massalin.27s Synthesis kernel|Synthesis]], would adjust the priority of each task as they ran according to the fullness of their input and output buffers.<ref>{{Cite web|url=https://lwn.net/Articles/270081/|title=KHB: Synthesis: An Efficient Implementation of Fundamental Operating Systems Services|website=lwn.net}}</ref>
This produces the same end result as using two redirects and a temporary file, as in:
<syntaxhighlight lang="
$ command1 > tempfile
$ command2 < tempfile
$ rm tempfile
</syntaxhighlight>
Line 54 ⟶ 63:
In casual use, the initial step of a pipeline is often <code>cat</code> or <code>echo</code>, 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:
<syntaxhighlight lang="
$ cat infile |
$ echo $string |
$ echo -e 'user\npass' | ftp localhost
</syntaxhighlight>
can be replaced by:
<syntaxhighlight lang="
$ ftp localhost <<< $'user\npass'
</syntaxhighlight>
As <code>echo</code> 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 shell]]s derived from the original [[Bourne shell]], the first two actions can be further modified by placing a number (the [[file descriptor]]) immediately before the [[token (parser)|character]]; this will affect which stream is used for the redirection.<ref>{{Cite web|url=https://www.redhat.com/sysadmin/redirect-shell-command-script-output|title=How to redirect shell command output|first=Roberto|last=Nozaki|date=April 21, 2022|website=www.redhat.com}}</ref> The Unix standard I/O streams are:<ref>{{Cite web|url=https://www.gnu.org/software/bash/manual/html_node/Redirections.html|title=Redirections (Bash Reference Manual)|website=www.gnu.org}}</ref>
{| class="wikitable"
Line 83 ⟶ 92:
|}
For example,
In shells derived from [[C shell|csh]] (the [[C shell]]), the syntax instead appends the {{mono|&}} (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.
Another useful capability is to redirect one standard file handle to another. The most popular variation is to merge [[Standard streams#Standard error (stderr)|standard error]] into [[Standard streams#Standard output (stdout)|standard output]] so error messages can be processed together with (or alternately to) the usual output. For example,
If the merged output is to be piped into another program, the file merge sequence {{code|2>&1}} must precede the pipe symbol, thus,
A simplified but non-POSIX conforming form of the command,
It is possible to use <code>2>&1</code> before "<code>></code>" but the result is commonly misunderstood.
Line 98 ⟶ 107:
Then "<code>></code>" redirects handle <code>1</code> to something else, e.g. a file, but it does '''not''' change handle <code>2</code>, 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, <syntaxhighlight lang="bash" inline>sort infile | uniq -c | sort -n > outfile</syntaxhighlight> sorts the lines of {{mono|infile}} in lexicographical order, writes unique lines prefixed by the number of occurrences, sorts the resultant output numerically, and places the final output in {{mono|outfile}}.<ref>{{Cite web|url=https://www.linux.org/threads/piping-and-redirecting-output-in-the-linux-terminal.43745/|title=Piping and Redirecting Output in the Linux Terminal |website=Linux.org}}</ref> This type of construction is used very commonly in [[shell script]]s and [[batch file]]s.
==Redirect to multiple outputs==
Line 109 ⟶ 118:
==See also==
* [[Here-document]], a way of specifying text for input in command
* [[Shell shoveling]]
* [[Command substitution]]
* [[Process substitution]]
* [[Console redirection]]
== References ==
{{Reflist}}
== Sources ==
* {{cite journal | last=Feiertag | first=R. J. | last2=Organick | first2=E. I. | title=The Multics input/output system | journal=ACM SIGOPS Operating Systems Review | volume=6 | issue=1/2 | date=1972 | issn=0163-5980 | doi=10.1145/850614.850622 | pages=35–38}}
* {{cite journal | last=Kernighan | first=Brian W. | last2=Morgan | first2=Samuel P. | title=The UNIX Operating System: A Model for Software Design | journal=Science | publisher=American Association for the Advancement of Science | volume=215 | issue=4534 | year=1982 | eissn=00368075 | issn=10959203 | jstor=1687467 | pages=779–783 | url=http://www.jstor.org/stable/1687467 | access-date=2024-04-25}}
==External links==
Line 127 ⟶ 144:
[[Category:Unix]]
[[Category:Windows administration]]
| |||