Standard streams

This article is about standard I/O file descriptors. For System V streams, see STREAMS.

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.

Application

The standard streams for input, output, and error

Users generally know these streams as mediums by which text incoming from an input device and text outgoing to display are handled. As they are used for input and output devices, they generally contain text, a sequence of characters in a predetermined encoding, such as Latin-1 or UTF-8.

These streams can also be chained; 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 control which part of the output stream appears on the display.

Although the familiar interactive usage is for the standard streams to contain text, they are also often used 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 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. 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 — 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 (stdin)

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 (stdout)

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.

Unless redirected, standard output is 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 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]

Timeline

1950s: Fortran

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.

! FORTRAN 77 example
      PROGRAM MAIN
        INTEGER NUMBER
        READ(UNIT=5,*) NUMBER
        WRITE(UNIT=6,'(A,I3)') ' NUMBER IS: ',NUMBER
      END
! Fortran 2003 example
program main
  use iso_fortran_env
  implicit none
  integer :: number
  read (unit=INPUT_UNIT,*) number
  write (unit=OUTPUT_UNIT,'(a,i3)') 'Number is: ', number
end program

1960: ALGOL 60

ALGOL 60 was criticized for having no standard file access.

1968: ALGOL 68

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.

Example 
# 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 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.

Thompson modified sort in Version 5 Unix to accept "-" as representing standard input, which spread to other utilities and became a part of the operating system as a special file in Version 8. Diagnostics were part of standard output through Version 6, after which Dennis M. Ritchie created the concept of standard error.[6]

1995: Java

In Java, the standard streams are referred to by System.in (for stdin), System.out (for stdout), and System.err (for stderr).[7]

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();
            try {
                double number = Double.parseDouble(line);
                System.out.println("Number is: " + number);
            } catch (Exception e) {
                System.err.println("Error:" + e.getMessage());
            }
        }
    }

2000s: .NET

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). 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# 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 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.

The Common Lisp Interface Manager paradigm "presents" GUI elements sent to an extended output stream.

See also

References

  1. ↑ D. M. Ritchie, "A Stream Input-Output System", AT&T Bell Laboratories Technical Journal, 68(8), October 1984.
  2. ↑ "<unistd.h>". The Open Group Base Specifications Issue 6—IEEE Std 1003.1, 2004 Edition. The Open Group. 2004.
  3. ↑ Steve Johnson (2013-12-11). "[TUHS] Graphic Systems C/A/T phototypesetter". The Unix Heritage Society. Retrieved 2015-07-02. External link in |work= (help)
  4. ↑ Revised Report on the Algorithmic Language Algol 68, Edited by A. van Wijngaarden, B.J. Mailloux, J.E.L. Peck, C.H.A. Koster, M. Sintzoff, C.H. Lindsey, L.G.L.T. Meertens and R.G. Fisker, http://www.softwarepreservation.org/projects/ALGOL/report/Algol68_revised_report-AB.pdf, Section 10.3
  5. ↑ http://linux.die.net/man/3/stdin
  6. ↑ McIlroy, M. D. (1987). A Research Unix reader: annotated excerpts from the Programmer's Manual, 1971–1986 (PDF) (Technical report). CSTR. Bell Labs. 139.
  7. ↑ "System (Java Platform SE 7)". Retrieved 20 July 2012.

External links

This article is issued from Wikipedia - version of the Wednesday, April 27, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.