Is stdout Ever Anything Other Than a Console Window?

Question

From http://www.cplusplus.com/reference/iostream/cout/:

By default, most systems have their standard output set to the console, where text messages are shown, although this can generally be redirected.

I've never heard of a system where stdout is anything other than a console window, by default or otherwise. I can see how redirecting it might be beneficial in systems where printing is an expensive operation, but that shouldn't be an issue in modern computers, right?

Answer 1

Of course it could be. I may want to redirect standard out to a text file, another process, a socket, whatever.

By default it is the Console, but the are a variety of reasons to redirect it, the most useful (in step with the Unix philosophy) being the redirection of the output of one program to the input of another program. This allows one to create many small, lightweight programs that feed into one another and work as discrete parts of a larger system.

Basically, it's just a simple yet powerful mechanism for sharing data. It is more popular on *nix systems for the reason I mention above, but it applies to Windows as well.

Answer 2

On most systems you can redirect the standard input/output/error to other file descriptors or locations.

For example (on Unix):

./appname > output

Redirects the stdout from appname to a file named output.

./appname 2> errors > output

Redirects stdout to a file named output, and all errors from stderr to a file named errors.

On unix systems you can also have a program open a file descriptor and point it at stdin, such as this:

echo "input" > input
cat input | ./appname

This will cause the program to read from the pipe for stdin.

---

This is how in unix you can "pipe" various different utilities together to create one larger tool.

find . -type f | ./appname | grep -iv "search"

This will run the find command, and take its output and pipe it into ./appname, then appname's output will be sent to grep's input which then searches for the word "search", displaying just the results that match.

It allows many small utilities to have a very powerful effect.

---

Think of the >, <, and | like plumbing.

> is like the drain in a sink, it accepts data and stores it where you want to put it. When a shell encounters the > it will open a file.

> file

When the shell sees the above, it will open the file using a standard system call, and remember that file descriptor. In the above case since there is no input it will create an empty file and allow you to type more commands.

banner Hello

This command writes Hello in really big letters to the console, and will cause it to scroll (I am using Unix here since it is what I know best). The output is simply written to standard out. Using a "sink" (>) we can control where the output goes, so

banner Hello > bannerout

will cause all of the data from banner's standard output to be redirected to the file descriptor the shell has opened and thus be written to a file named bannerout.

Pipes work similarly to >'s in that they help control the flow of where the data goes. Pipes however can't write to files, and can only be used to help the flow of data go from one point to another.

For example, here is water flowing through several substations and waste cleaning:

pump --from lake | treatment --cleanse-water | pump | reservoir | pump > glass

The water flows from the lake, through a pipe to the water treatment plant, from the plant back into a pump that moves it to a reservoir, then it is pumped once more into the municipal water pipes and through your sink into your glass.

Notice that the pipes simply connect all of the outputs together, ultimately it ends up in your glass.

It is the same way with commands and processing them in a shell on Linux. It also follows a path to get to an end result.

Now there is one final thing that I hadn't discussed yet in my previous statements, that is the < input character. What it does is read from a file and output it to stdin on programs.

cat < bannerout

Will simply print what was stored in bannerout. This can be used if you have a file you want to process, but don't want to prepend cat <file> because of not wanting to run an extra command in the chain.

So try this:

echo "Hello" > bannerinput
banner < bannerinput

This will first put the string "Hello" in the file bannerinput, and then when your run banner it will read from the file bannerinput.

I hope this helps you understand how redirection and pipping works on Unix (some if not most will apply to Windows as well).