In computer programming, standard streams are preconnected input and output communication channels[1] between a computer program and its environment when it begins execution. The three I/O connections are called standard input (stdin), standard output (stdout) and standard error (stderr). Originally I/O happened via a physically connected system console (input via keyboard, output via monitor), but standard streams abstract this. When a command is executed via an interactive shell, the streams are typically connected to the text terminal on which the shell is running, but can be changed with redirection, e.g. via a pipeline. More generally, a child process will inherit the standard streams of its parent process.

Users generally know standard streams as input and output channels that handle data coming from an input device, or that write data from the application. The data may be text with any encoding, or binary data.

Streams may be used to chain applications, meaning the output of a program is used for input to another application. In many operating systems this is expressed by listing the application names, separated by the vertical bar character, for this reason often called the pipeline character. A well-known example is the use of a pagination application, such as more, providing the user control over the display of the output stream on the display.

In most operating systems predating Unix, programs had to explicitly connect to the appropriate input and output devices. OS-specific intricacies caused this to be a tedious programming task. On many systems it was necessary to obtain control of environment settings, access a local file table, determine the intended data set, and handle hardware correctly in the case of punch card reader, magnetic tape drive, disk drive, line printer, card punch, or interactive terminal.

One of Unix's several groundbreaking advances was abstract devices, which removed the need for a program to know or care what kind of devices it was communicating with.[citation needed] Older operating systems forced upon the programmer a record structure and frequently non-orthogonal data semantics and device control. Unix eliminated this complexity with the concept of a data stream: an ordered sequence of data bytes which can be read until the end of file. A program may also write bytes as desired and need not (and can't easily) declare how many there will be, or how they will be grouped.

Another Unix breakthrough was to automatically associate input and output by default[citation needed] — the program (and programmer) did absolutely nothing to establish input and output for a typical input-process-output program (unless it chose a different paradigm). In contrast, previous operating systems usually required some—often complex—job control language to establish connections, or the equivalent burden had to be orchestrated by the program.

Since Unix provided standard streams, the Unix C runtime environment was obliged to support it as well. As a result, most C runtime environments (and C's descendants), regardless of the operating system, provide equivalent functionality.

Standard input is stream data (often text) going into a program. The program requests data transfers by use of the read operation. Not all programs require stream input. For example, the dir and ls programs (which display file names contained in a directory) may take command-line arguments, but perform their operations without any stream data input.

Unless redirected, standard input is expected from the keyboard which started the program.

The file descriptor for standard input is 0 (zero); the POSIX<unistd.h> definition is STDIN_FILENO; the corresponding <stdio.h> variable is FILE* stdin; similarly, the <iostream> variable is std::cin.

Standard output is the stream where a program writes its output data. The program requests data transfer with the write operation. Not all programs generate output. For example, the file rename command (variously called mv, move, or ren) is silent on success.

The file descriptor for standard output is 1 (one); the POSIX<unistd.h> definition is STDOUT_FILENO; the corresponding <stdio.h> variable is FILE* stdout; similarly, the <iostream> variable is std::cout.

Standard error is another output stream typically used by programs to output error messages or diagnostics. It is a stream independent of standard output and can be redirected separately. This solves the semipredicate problem, allowing output and errors to be distinguished, and is analogous to a function returning a pair of values – see Semipredicate problem: Multivalued return. The usual destination is the text terminal which started the program to provide the best chance of being seen even if standard output is redirected (so not readily observed). For example, output of a program in a pipeline is redirected to input of the next program, but errors from each program still go directly to the text terminal.

It is acceptable—and normal—for standard output and standard error to be directed to the same destination, such as the text terminal. Messages appear in the same order as the program writes them, unless buffering is involved. (For example, a common situation is when the standard error stream is unbuffered but the standard output stream is line-buffered; in this case, text written to standard error later may appear on the terminal earlier, if the standard output stream's buffer is not yet full.)

The file descriptor for standard error is defined by POSIX as 2 (two); the <unistd.h> header file provides the symbol STDERR_FILENO;[2] the corresponding <stdio.h> variable is FILE* stderr. The C++ <iostream> standard header provides two variables associated with this stream: std::cerr and std::clog, the former being unbuffered and the latter using the same buffering mechanism as all other C++ streams.

Bourne-style shells allow standard error to be redirected to the same destination that standard output is directed to using

2>&1

csh-style shells allow standard error to be redirected to the same destination that standard output is directed to using

>&

Standard error was added to Unix after several wasted phototypesetting runs ended with error messages being typeset instead of displayed on the user's terminal. [3]

Fortran has the equivalent of Unix file descriptors: By convention, many Fortran implementations use unit numbers UNIT=5 for stdin, UNIT=6 for stdout and UNIT=0 for stderr. In Fortran-2003, the intrinsic ISO_FORTRAN_ENV module was standardized to include the named constants INPUT_UNIT, OUTPUT_UNIT, and ERROR_UNIT to portably specify the unit numbers.

ALGOL 68's input and output facilities were collectively referred to as the transput.[4]Koster coordinated the definition of the transput standard. The model included three standard channels: stand in, stand out, and stand back.

In the C programming language, the standard input, output, and error streams are attached to the existing Unix file descriptors 0, 1 and 2 respectively.[5] In a POSIX environment the <unistd.h> definitions STDIN_FILENO, STDOUT_FILENO or STDERR_FILENO should be used instead rather than magic numbers. File pointers stdin, stdout, and stderr are also provided.

In C# and other .NET languages, the standard streams are referred to by System.Console.In (for stdin), System.Console.Out (for stdout) and System.Console.Error (for stderr).[citation needed] Basic read and write capabilities for the stdin and stdout streams are also accessible directly through the class System.Console (e.g. System.Console.WriteLine() can be used instead of System.Console.Out.WriteLine()).

System.Console.In, System.Console.Out and System.Console.Error are System.IO.TextReader (stdin) and System.IO.TextWriter (stdout, stderr) objects, which only allow access to the underlying standard streams on a text basis. Full binary access to the standard streams must be performed through the System.IO.Stream objects returned by System.Console.OpenStandardInput(), System.Console.OpenStandardOutput() and System.Console.OpenStandardError() respectively.

// C# examplepublicstaticintMain(string[]args){try{strings=System.Console.In.ReadLine();doublenumber=double.Parse(s);System.Console.Out.WriteLine("Number is: {0:F3}",number);return0;// If Parse() threw an exception}catch(System.ArgumentNullException){System.Console.Error.WriteLine("No number was entered!");}catch(System.FormatException){System.Console.Error.WriteLine("The specified value is not a valid number!");}catch(System.OverflowException){System.Console.Error.WriteLine("The specified number is too big!");}return-1;}

' Visual Basic .NET examplePublicFunctionMain()AsIntegerTryDimsAsString=System.Console.[In].ReadLine()DimnumberAsDouble=Double.Parse(s)System.Console.Out.WriteLine("Number is: {0:F3}",number)Return0' If Parse() threw an exceptionCatchexAsSystem.ArgumentNullExceptionSystem.Console.[Error].WriteLine("No number was entered!")Catchex2AsSystem.FormatExceptionSystem.Console.[Error].WriteLine("The specified value is not a valid number!")Catchex3AsSystem.OverflowExceptionSystem.Console.[Error].WriteLine("The specified number is too big!")EndTryReturn-1EndFunction

When applying the System.Diagnostics.Processclass one can use the instance propertiesStandardInput, StandardOutput, and StandardError of that class to access the standard streams of the process.

Graphical user interfaces (GUIs) rarely make use of the standard streams. Consequently, redirecting GUI programs or constructing a GUI pipeline is neither practical nor useful. The nearest analogy is probably cutting (or copying) from one application and pasting into another. Since manual user operations are required, moving large numbers of pastes is not especially efficient. The Services menu, as implemented on NeXTSTEP and Mac OS X, is also analogous to standard streams. On these operating systems, graphical applications can provide functionality through a systemwide menu that operates on the current selection in the GUI, no matter in what application.

Some GUI programs, primarily on Unix, still write debug information to standard error. Others (such as many Unix media players) may read files from standard input. Popular Windows programs that open a separate console window in addition to their GUI windows are the emulators pSX and DOSBox.

GTK-server can use stdin as a communication interface with an interpreted program to realize a GUI.