No software is worth anything if there is no output of some sort. But I/O (Input/ Output) has long been one of the nastier areas of computing. If you’re ancient, you remember the days most of the work involved in running a program was setting up the program’s input and output. Some of the problems have gone away; for example, you no longer need to get operators to mount tapes on a tape drive (not on any laptop or desktop system that I’ve seen). But many of the problems are still with us.

One problem is that there are many different types of output. Writing something on the screen is different from writing something in a file—at least, it sure seems different. Writing something in a file seems different from writing it on a tape, or in flash memory, or on some other kind of device. And what if you want the output from one program to go directly into another program? Should software developers be tasked with writing code to handle all sorts of output devices, even ones that haven’t been invented yet? That’s certainly inconvenient. Should users have to know how to connect the programs they want to run to different kinds of devices? That’s not a very good idea, either.

One of the most important ideas behind the Unix operating system was that everything looked like a file (an ordered sequence of bytes). The operating system was responsible for this magic. It didn’t matter whether you were writing to a file on the disk, the terminal, a tape drive, a memory stick, or something else; your program only needed to know how to write to a file, and the operating system would take it from there. That approach greatly simplified the problem. The next question was, simply, “which file?” How does a program know whether to write to the file that represents a terminal window, a file on the disk, or some other kind of file? Simple: that’s something that can be left to the shell.

When you run a program, you still have to connect it to output files and input files (which we’ll see in the next chapter). That task doesn’t go away. But the shell makes it trivially easy. A command as simple as:

$ dosomething < inputfile > outputfile

reads its input from inputfile and sends its output to outputfile. If you omit > outputfile, the output goes to your terminal window. If you omit <inputfile, the program takes its input from the keyboard. The program literally doesn’t know where its output is going, or where its input is coming from. You can send the out-put anywhere you want (including to another program) by using bash’s redirection facilities.

But that’s just the start. In this chapter, we’ll look at ways to generate output, and the shell’s methods for sending that output to different places.