How to Think About UNIX

If you'll be working with FreeBSD, you should understand some of the UNIX ways of thinking. Users from a Windows background might very well go into shock during their first attempts to administer a FreeBSD system if they don't understand how UNIX behaves, and how it expects you to behave.

People who are used to GUI environments, such as Windows and Macintosh, are probably unfamiliar with how UNIX handles input and output. If you are new to UNIX, you may be used to clicking something and seeing either an "OK" message, an error, nothing, or (all too often) a pretty blue screen with nifty high−tech letters explaining exactly where the system crashed. UNIX does things a little differently.

Channels of Communication

UNIX programs have three "channels" of communication: standard input, standard output, and standard error. Once you understand how each of these channels work, you're a good way along to understanding how a computer works.

Standard input is the source of information. When you're at the console typing a command, the standard input is the keyboard. If your program is listening to the network, the standard input is the network. Many programs can rearrange standard input to accept data from the network, a file, the keyboard, or any other source.

The standard output is where the program's output is displayed. This is frequently the console (screen). Network programs usually return the output to the network.

Finally, standard error is where error messages are sent. Frequently, console programs return errors to the console; others log errors to a file.

Working with Channels

The channels just described can be arbitrarily arranged, a concept that is perhaps the biggest hurdle for new UNIX users and admins. While it seems simple enough, it's slightly more difficult to grow accustomed to than you might think.

For example, if you don't like the error messages appearing on the terminal, you can redirect them to a file. If you don't want to type a list of information into a command, you can put the information in a file (so you can reuse it), and dump the file into the standard input of your command. Or better still, run a command to generate that information and put it in a file, or just pipe (send) it directly to your second command.

The Command Line

Taken to its logical extreme, these input/output channels can overwhelm a new user. The first time I saw someone type something like the following on a command line during my UNIX admin training, I wanted to change careers.

...............................................................................................

# tail −f /var/log/messages | grep −v sudo | grep −v named &

...............................................................................................

14

Lines of incomprehensible text began spilling across the screen. And worse still, my trainer kept typing as this output poured out!

If you're coming from a point−and−click environment, a long string of commands like this is definitely intimidating. What do all those funky words mean, let alone the symbols?

Think of learning to use the command line as learning a language. When learning a language, we start with simple words. As we increase our vocabulary, we also learn how to string words together. Learning to use the UNIX command line is like learning a language. You begin with simple single commands and only later string them together into monstrosities like the one shown earlier.

Another difficulty people have is with the general UNIX program function philosophy. Most consumer operating systems have monolithic software packages that try to be all things to all people. UNIX programs are small, simple tools. That's in part because of the redirectable input/output channels, and in part because of UNIX's heritage. Remember, at one time you needed to be a programmer to run a UNIX system. Programmers don't mind building their own tools. Assembling a tool on the command line is fairly easy compared to compiling a whole software package.

These smaller programs also provide unparalleled flexibility. Have you ever wished you could use a function from one program in another program? By using a variety of smaller programs and arranging the inputs and outputs as you like, you can make the system behave in any manner that amuses you. Many modern platforms have only started catching up with this idea of small, reusable tools in the last few years.

15