See
stdout. In a
C program (as well as many other languages) on a
Unix-style
OS, this is basically the default
file descriptor for output (usually has a numerical value of 1). See also
standard input or
stdin and
standard error or
stderr.
Here is an example of using standard output in Perl:
print "This text will go to standard output!\n";
print STDOUT "So will this!!\n";
print STDERR ":( But not this...\n";
print STDIN "And this will probably not die... but will be a noop.\n";
So, from the above example you can see 4
strings getting printed to three different "places". The first two both go to standard output, the third goes to
standard error and the last goes to
standard input (the last is a non-fatal error, you can't really write to a readonly
filehandle in perl.)
What does this mean for the layman? Well it's a minor detail of programming that can be illustrated best from a user shell.
Suppose you were using Unix bash and you had this program called 'webserver' that served a site identical to but not as cool as everything2.com. Also suppose this program was a console application (it doesn't have a GUI so you have to run it from a text-based shell). Also suppose that this program printed out useful information suitable for piping into another program such as the IP address of every hit -- this would go to standard output. More verbose information such as say a status update every 100 hits or a sporadic error message isn't suitable for telling any 1 program about (as it's random, chaotic, non-computer-readable, and liable inherently non-deterministic) so that would be in the standard error stream.
You would run the program 'webserver' as follows, and see the following output:
[me@mybox]$ cd /opt/webserver && ./webserver
Webserver 1.0!
Welcome to webserver!
Hit #1 from 127.0.0.1 requested blah.html
Hit #2 from 192.168.0.1 requested blah2.html
.
.
. (and on the 100th hit)
Hit #100 from 10.10.10.1 requested blah.html
Usage update -- TimeStamp: {SOME TIME HERE} Hits: 100 %memory usage: 5.03 Disk usage: 100MB
.
.
.
Hit #200 from 10.10.10.15 requested lala.jpg
Usage update -- TimeStamp: {SOME TIME HERE} Hits: 200 %memory usage: 5.04 Disk usage: 103MB
.
.
Warning! Memory usage exceeded 99% on hit 275!
Hit #275 from 66.66.66.66 requested /cgi-bin/backdoorexploit.pl?password=rubarb
.
.
.
and so on
Now the fact that you have a standard error stream and a standard output stream are useful for just such a case. Normally they both go to the terminal (printed as text to the screen). But, if you so wanted, you can log all the ip addresses and requests to your site using output redirection notated in the bourne shell using the '>' character. That way you can filter out the obtrusive but regular stdout messages and throw them in a file, and put the irregular but critical stderr messages to the screen. Recall that the usage update went to standard error. That would be done as follows:
[me@mybox]$ cd /opt/webserver && ./webserver > /tmp/log1.log
The above redirects the standard output to a file, and still allows standard error to go to the screen, so your session would then print the followint to the screen:
Webserver 1.0!
Welcome to webserver!
Usage update -- TimeStamp: {SOME TIME HERE} Hits: 100 %memory usage: 5.03 Disk usage: 100MB
Usage update -- TimeStamp: {SOME TIME HERE} Hits: 200 %memory usage: 5.04 Disk usage: 103MB
Warning! Memory usage exceeded 99% on hit 275!
And the following to your text file /tmp/log1.log:
Hit #1 from 127.0.0.1 requested blah.html
Hit #2 from 192.168.0.1 requested blah2.html
.
.
Hit #100 from 10.10.10.1 requested blah.html
.
.
.
Hit #200 from 10.10.10.15 requested lala.jpg
.
.
.
Hit #275 from 66.66.66.66 requested /cgi-bin/backdoorexploit.pl?password=rubarb
.
.
. (and so on)
I think it's cool that the original designers of Unix had the foresight to default a process to having at least two separate streams for program output. Does it seem just like an arbitrary choice they made? Maybe. But I think if you read more about Unix pipes you will see why its necessary to have regular program output go to standard output (to that it can be piped to another program, and irregular error conditions go to standard error.
In general the separation of streams allows for reliable operations of pipes and still permits the logging of errors. On a slightly unrelated note, check out this node.