Standard streams: Difference between revisions
Yamaguchi先生 (talk | contribs) m Reverted edits by 136.160.90.6 (talk) to last version by Eeera |
No edit summary |
||
Line 2: | Line 2: | ||
{{More footnotes|date=March 2010}} |
{{More footnotes|date=March 2010}} |
||
In [[computer programming]], '''standard |
In [[computer programming]], '''standard channels''' are preconnected input and output communication channels between a computer program and its environment when it begins execution. The three [[input/output|I/O]] channels 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 channels (file handles) and generic streams abstract this. When a command is executed via a [[Shell (computing)|shell]], the standard channels are typically connected to the [[text terminal]] in which the shell is running, but can be changed with [[Redirection (computing)|redirection]], particularly via a [[Pipeline (Unix)|pipeline]]. However, [[Daemon (computing)|daemon]]s do not have pre-connected channels. More generally, a [[child process]] will inherit the standard channels of its [[parent process]]. |
||
==Application == |
==Application == |
||
[[Image:Stdstreams-notitle.svg|thumb|right|The standard |
[[Image:Stdstreams-notitle.svg|thumb|right|The standard channels for input, output, and error]] |
||
Users generally know these |
Users generally know these channels as mediums by which streams of text incoming from an input device and streams of text outgoing to display are handled. As they are used for input and output devices, they generally transmit text, a sequence of characters in a predetermined [[encoding]], such as [[ISO/IEC 8859-1|Latin-1]] or [[UTF-8]].{{cn|date=October 2014}} |
||
These |
These channels can also be connected one to another; the output of a program can then be the input of another one. A well-known example is the use of a pager such as [[more (command)|more]], which gives the user a way to filter the output stream before sending it to the display. |
||
Although the dominant usage is for the standard |
Although the dominant usage is for the standard channels to stream text, it is possible to use them to transfer arbitrary [[Binary file|binary data]]. |
||
==Background== |
==Background== |
||
Line 19: | Line 19: | ||
Another Unix breakthrough was to automatically associate input and output by default{{cn|date=December 2013}} — 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|job control language]] to establish connections, or the equivalent burden had to be orchestrated by the program. |
Another Unix breakthrough was to automatically associate input and output by default{{cn|date=December 2013}} — 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|job control language]] to establish connections, or the equivalent burden had to be orchestrated by the program. |
||
Since Unix provided standard |
Since Unix provided standard connections, the Unix [[C (programming language)|C]] runtime environment was obliged to support it as well. As a result, most C runtime environments (and [[C_(programming_language)#Related_languages|C's descendants]]), regardless of the operating system, provide equivalent functionality. |
||
==Standard input (stdin)==<!-- This section is linked from [[COMMAND.COM]] --> |
==Standard input (stdin)==<!-- This section is linked from [[COMMAND.COM]] --> |
||
Standard input is data (often text) |
Standard input is the channel used to send data (often text) *into* a program. The program requests data transfers by use of the ''read'' operation. Not all programs require input. For example, the ''[[dir (command)|dir]]'' and ''[[ls]]'' programs (which display file names contained in a directory) perform their operations without any stream data input. |
||
Unless [[Redirection (computing)|redirected]], input is |
Unless [[Redirection (computing)|redirected]], input is connected to the [[Keyboard (computing)|keyboard]] which started the program. |
||
The [[file descriptor]] for standard input is 0 (zero); the [[POSIX]] ''<unistd.h>'' definition is <tt>STDIN_FILENO</tt>; the corresponding ''<stdio.h>'' variable is <tt>FILE* stdin</tt>; similarly, the ''<iostream>'' variable is <tt>std::cin</tt>. |
The [[file descriptor]] for standard input is 0 (zero); the [[POSIX]] ''<unistd.h>'' definition is <tt>STDIN_FILENO</tt>; the corresponding ''<stdio.h>'' variable is <tt>FILE* stdin</tt>; similarly, the ''<iostream>'' variable is <tt>std::cin</tt>. |
||
==Standard output (stdout)==<!-- This section is linked from [[COMMAND.COM]] --> |
==Standard output (stdout)==<!-- This section is linked from [[COMMAND.COM]] --> |
||
Standard output is the |
Standard output is the connection where a program writes its output data. The program requests data transfer with the ''write'' operation. Not all programs generate output. For example the ''[[rename (computing)|file rename]]'' command (variously called ''[[mv]]'', ''[[move (command)|move]]'', or ''ren'') is silent on success. |
||
Unless [[Redirection (Unix)|redirected]], standard output is the [[text terminal]] which initiated the program. |
Unless [[Redirection (Unix)|redirected]], standard output is connected to the [[text terminal]] which initiated the program. |
||
The [[file descriptor]] for standard output is 1 (one); the [[POSIX]] ''<unistd.h>'' definition is <tt>STDOUT_FILENO</tt>; the corresponding ''<stdio.h>'' variable is <tt>FILE* stdout</tt>; similarly, the ''<iostream>'' variable is <tt>std::cout</tt>. |
The [[file descriptor]] for standard output is 1 (one); the [[POSIX]] ''<unistd.h>'' definition is <tt>STDOUT_FILENO</tt>; the corresponding ''<stdio.h>'' variable is <tt>FILE* stdout</tt>; similarly, the ''<iostream>'' variable is <tt>std::cout</tt>. |
||
==Standard error (stderr)==<!-- This section is linked from [[COMMAND.COM]] --> |
==Standard error (stderr)==<!-- This section is linked from [[COMMAND.COM]] --> |
||
Standard error is another output |
Standard error is another output connection typically used by programs to output [[error message]]s or diagnostics streams. It is a independent connection 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|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 (Unix)|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 |
It is acceptable—and normal—for ''standard output'' and ''standard error'' to be connected 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 connection is unbuffered but the standard output connection is line-buffered; in this case, text written to standard error later may appear on the terminal earlier, if the standard output connection'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 <tt>STDERR_FILENO</tt>;<ref>{{cite web |url=http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html |work=The Open Group Base Specifications Issue 6—IEEE Std 1003.1, 2004 Edition |title=<unistd.h> |publisher=The Open Group |year=2004 }}</ref> the corresponding ''<stdio.h>'' variable is <tt>FILE* stderr</tt>. The C++ ''<iostream>'' standard header provides two variables associated with this stream: <tt>std::cerr</tt> and <tt>std::clog</tt>, the former being unbuffered and the latter using the same buffering mechanism as all other C++ streams. |
The [[file descriptor]] for standard error is defined by [[POSIX]] as 2 (two); the ''<unistd.h>'' header file provides the symbol <tt>STDERR_FILENO</tt>;<ref>{{cite web |url=http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html |work=The Open Group Base Specifications Issue 6—IEEE Std 1003.1, 2004 Edition |title=<unistd.h> |publisher=The Open Group |year=2004 }}</ref> the corresponding ''<stdio.h>'' variable is <tt>FILE* stderr</tt>. The C++ ''<iostream>'' standard header provides two variables associated with this stream: <tt>std::cerr</tt> and <tt>std::clog</tt>, the former being unbuffered and the latter using the same buffering mechanism as all other C++ streams. |
||
Line 89: | Line 89: | ||
=== 1970s: C and Unix === |
=== 1970s: C and Unix === |
||
In the '''[[C (programming language)|C programming language]]''', the standard input, output, and error |
In the '''[[C (programming language)|C programming language]]''', the standard input, output, and error connections are the Unix file descriptors 0, 1 and 2 respectively.<ref>http://linux.die.net/man/3/stdin</ref> In a [[POSIX]] environment the ''<[[unistd.h]]>'' definitions ''STDIN_FILENO'', ''STDOUT_FILENO'' or ''STDERR_FILENO'' should be used instead rather than [[Magic number (programming)|magic numbers]]. File handles ''stdin'', ''stdout'', and ''stderr'' are also provided. |
||
===1995: Java === |
===1995: Java === |
||
In [[Java (programming language)|Java]], the standard |
In [[Java (programming language)|Java]], the standard connections are referred to by {{Javadoc:SE|java/lang|System|in}} (for stdin), {{Javadoc:SE|java/lang|System|out}} (for stdout), and {{Javadoc:SE|java/lang|System|err}} (for stderr).<ref>{{cite web|title=System (Java Platform SE 7)|url=http://docs.oracle.com/javase/7/docs/api/java/lang/System.html|accessdate=20 July 2012}}</ref> |
||
<source lang="java"> |
<source lang="java"> |
||
public static void main(String args[]) { |
public static void main(String args[]) { |
||
Line 119: | Line 119: | ||
===2000s: .NET === |
===2000s: .NET === |
||
In [[C Sharp (programming language)|C#]] and other [[.NET Framework|.NET]] languages, the standard |
In [[C Sharp (programming language)|C#]] and other [[.NET Framework|.NET]] languages, the standard connections are referred to by <code>System.Console.In</code> (for stdin), <code>System.Console.Out</code> (for stdout) and <code>System.Console.Error</code> (for stderr).{{citation needed|date=February 2012}} Basic read and write capabilities for the stdin and stdout are also accessible directly through the class <code>System.Console</code> (e.g. <code>System.Console.WriteLine()</code> can be used instead of <code>System.Console.Out.WriteLine()</code>). |
||
<code>System.Console.In</code>, <code>System.Console.Out</code> and <code>System.Console.Error</code> are <code>System.IO.TextReader</code> (stdin) and <code>System.IO.TextWriter</code> (stdout, stderr) objects, which only allow access to the underlying standard |
<code>System.Console.In</code>, <code>System.Console.Out</code> and <code>System.Console.Error</code> are <code>System.IO.TextReader</code> (stdin) and <code>System.IO.TextWriter</code> (stdout, stderr) objects, which only allow access to the underlying standard connections on a text basis. Full binary access to the standard connections must be performed through the <code>System.IO.Stream</code> objects returned by <code>System.Console.OpenStandardInput()</code>, <code>System.Console.OpenStandardOutput()</code> and <code>System.Console.OpenStandardError()</code> respectively. |
||
<source lang="csharp"> |
<source lang="csharp"> |
||
// C# example |
// C# example |
||
Line 171: | Line 171: | ||
===GUIs=== |
===GUIs=== |
||
[[Graphical user interface]]s (GUIs) rarely make use of the standard |
[[Graphical user interface]]s (GUIs) rarely make use of the standard connections.{{citation needed|date=February 2012}} 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 (emulator)|pSX]] and [[DOSBox]]. |
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 (emulator)|pSX]] and [[DOSBox]]. |
||
Line 177: | Line 177: | ||
[[GTK-server]] can use stdin as a communication interface with an interpreted program to realize a GUI. |
[[GTK-server]] can use stdin as a communication interface with an interpreted program to realize a GUI. |
||
The [[CLIM|Common Lisp Interface Manager]] paradigm "presents" GUI elements sent to an extended output |
The [[CLIM|Common Lisp Interface Manager]] paradigm "presents" GUI elements sent to an extended output connection. |
||
==See also== |
==See also== |
Revision as of 19:35, 23 January 2015
This article includes a list of general references, but it lacks sufficient corresponding inline citations. (March 2010) |
In computer programming, standard channels are preconnected input and output communication channels between a computer program and its environment when it begins execution. The three I/O channels 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 channels (file handles) and generic streams abstract this. When a command is executed via a shell, the standard channels are typically connected to the text terminal in which the shell is running, but can be changed with redirection, particularly via a pipeline. However, daemons do not have pre-connected channels. More generally, a child process will inherit the standard channels of its parent process.
Application
Users generally know these channels as mediums by which streams of text incoming from an input device and streams of text outgoing to display are handled. As they are used for input and output devices, they generally transmit text, a sequence of characters in a predetermined encoding, such as Latin-1 or UTF-8.[citation needed]
These channels can also be connected one to another; the output of a program can then be the input of another one. A well-known example is the use of a pager such as more, which gives the user a way to filter the output stream before sending it to the display.
Although the dominant usage is for the standard channels to stream text, it is possible to use them to transfer arbitrary binary data.
Background
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 an intimidating programming challenge. 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 connections, 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 (stdin)
Standard input is the channel used to send data (often text) *into* a program. The program requests data transfers by use of the read operation. Not all programs require input. For example, the dir and ls programs (which display file names contained in a directory) perform their operations without any stream data input.
Unless redirected, input is connected to 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 (stdout)
Standard output is the connection 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.
Unless redirected, standard output is connected to the text terminal which initiated the program.
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 (stderr)
Standard error is another output connection typically used by programs to output error messages or diagnostics streams. It is a independent connection 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 connected 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 connection is unbuffered but the standard output connection is line-buffered; in this case, text written to standard error later may appear on the terminal earlier, if the standard output connection'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;[1] 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.
Most shells[citation needed] allow both standard output and standard error to be redirected to the same file using
&> filename
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
>&
Timeline
1950s: Fortran
Fortran has the equivalent of Unix file descriptors: UNIT=5
for stdin, UNIT=6
for stdout and UNIT=0
for stderr[dubious – discuss][citation needed].
! FORTRAN 77 example
PROGRAM MAIN
READ(UNIT=5,*)NUMBER
WRITE(UNIT=6,'(F5.3)')' NUMBER IS: ',NUMBER
END
1960: ALGOL 60
ALGOL 60 was criticized for having no standard file access.[citation needed]
1968: ALGOL 68
ALGOL 68's input and output facilities were collectively referred to as the transput.[citation needed] Koster coordinated the definition of the transput standard. The model included three standard channels: stand in
, stand out
, and stand back
.
# ALGOL 68 example #
main:(
REAL number;
getf(stand in,($g$,number));
printf(($"Number is: "g(6,4)"OR "$,number)); # OR #
putf(stand out,($" Number is: "g(6,4)"!"$,number));
newline(stand out)
) | |
Input: | Output: |
---|---|
3.14159 |
Number is: +3.142 OR Number is: +3.142! |
1970s: C and Unix
In the C programming language, the standard input, output, and error connections are the Unix file descriptors 0, 1 and 2 respectively.[2] In a POSIX environment the <unistd.h> definitions STDIN_FILENO, STDOUT_FILENO or STDERR_FILENO should be used instead rather than magic numbers. File handles stdin, stdout, and stderr are also provided.
1995: Java
In Java, the standard connections are referred to by System.in
(for stdin), System.out
(for stdout), and System.err
(for stderr).[3]
public static void main(String args[]) {
try {
BufferedReader br =
new BufferedReader(new InputStreamReader(System.in));
String s = br.readLine();
double number = Double.parseDouble(s);
System.out.println("Number is:" + number);
} catch (Exception e) {
System.err.println("Error:" + e.getMessage());
}
}
Or you can use the Scanner
class of package java.util.
public static void main(String[] args) {
Scanner sc = new Scanner(System.in);
while(sc.hasNextLine()) {
String line = sc.nextLine();
double number = Double.parseDouble(line);
System.out.println("Number is: " + number);
}
}
2000s: .NET
In C# and other .NET languages, the standard connections 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 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 connections on a text basis. Full binary access to the standard connections must be performed through the System.IO.Stream
objects returned by System.Console.OpenStandardInput()
, System.Console.OpenStandardOutput()
and System.Console.OpenStandardError()
respectively.
// C# example
public static int Main(string[] args)
{
try {
string s = System.Console.In.ReadLine();
double number = double.Parse(s);
System.Console.Out.WriteLine("Number is: {0:F3}", number);
return 0;
// 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 example
Public Function Main() As Integer
Try
Dim s As String = System.Console.[In].ReadLine()
Dim number As Double = Double.Parse(s)
System.Console.Out.WriteLine("Number is: {0:F3}", number)
Return 0
' If Parse() threw an exception
Catch ex As System.ArgumentNullException
System.Console.[Error].WriteLine("No number was entered!")
Catch ex2 As System.FormatException
System.Console.[Error].WriteLine("The specified value is not a valid number!")
Catch ex3 As System.OverflowException
System.Console.[Error].WriteLine("The specified number is too big!")
End Try
Return -1
End Function
When applying the System.Diagnostics.Process
class one can use the instance properties StandardInput
, StandardOutput
, and StandardError
of that class to access the standard streams of the process.
GUIs
Graphical user interfaces (GUIs) rarely make use of the standard connections.[citation needed] 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.
The Common Lisp Interface Manager paradigm "presents" GUI elements sent to an extended output connection.
See also
- Redirection (computing)
- Pipeline (Unix)
- Stream (computing)
- Input/output
- C file input/output
- SYSIN and SYSOUT
References
- ^ "<unistd.h>". The Open Group Base Specifications Issue 6—IEEE Std 1003.1, 2004 Edition. The Open Group. 2004.
- ^ http://linux.die.net/man/3/stdin
- ^ "System (Java Platform SE 7)". Retrieved 20 July 2012.
- "Standard Streams", The GNU C Library
- KRONOS 2.1 Reference Manual, Control Data Corporation, Part Number 60407000, 1974
- NOS Version 1 Applications Programmer's Instant, Control Data Corporation, Part Number 60436000, 1978
- Level 68 Introduction to Programming on MULTICS, Honeywell Corporation, 1981
- Evolution of the MVS Operating System, IBM Corporation, 1981
- Lions' Commentary on UNIX Sixth Edition, John Lions, ISBN 1-57398-013-7, 1977
- Console Class, .NET Framework Class Library, Microsoft Corporation, 2008
External links
- Standard Input Definition - by The Linux Information Project
- Standard Output Definition - by The Linux Information Project
- Standard Error Definition - by The Linux Information Project