Linux, Unix, /etc/

$ To set up this Linux system, do I really have to type long, cryptic, frequently inconsistent and undocumented commands with occasional long strings of hex digits?

# Yeah. You got a problem with that?

Sponsored links (requires javascript):

The Unix Philosophy

The Command Line

While the rest of the world points and clicks in a scary little world of icons, all alike, we in the world of Unix get to use a good old-fashioned CLI, or Command Line Interface. One reason why the command line has remained so pervasive in Unix environments is that the implementation, the Unix shell in its various incarnations, is actually pretty damn good. It allows the user to use the tools provided to build new tools. This, by any other name, is programming. And programming is the essential activity of computing. Without it, a computer, however expensive the materials of which it is made, is no more than an expensive heap of junk. At all levels beyond the bare transistors, it is programs that make it what it is.

The unfortunate legions of office workers today saddled with Windows are obliged to worship their computer as an all-knowing god that can do no wrong, that is always finding fault with them; and consequently develop a fierce hatred for it. This is inevitable. One cannot effectively use any tool without some understanding of its workings.

Almost as soon as one begins to use Unix, one is programming the shell. The first pipeline one builds,

ls -l | less

for instance, is a small program in itself. Shell programming proper begins when such combinations of commands are put in a file where they can be run repeatedly. Unix makes no distinction between executable files of one stripe or another. A text file with execute permission containing our little pipeline above is no different to it, in principle, than GNU Chess. This is a great advantage, in that it allows us to "cut our coat to suit our cloth", so to speak, in choosing the most appropriate programming tool for the task in hand, secure in the knowledge that whatever we choose to build in, our finished product will be treated by the system as just another program.

The Toolbox

There are many people who use UNIX or Linux who IMHO do not understand UNIX. UNIX is not just an operating system, it is a way of doing things, and the shell plays a key role by providing the glue that makes it work. The UNIX methodology relies heavily on reuse of a set of tools rather than on building monolithic applications. Even perl programmers often miss the point, writing the heart and soul of the application as perl script without making use of the UNIX toolkit.
—David Korn
"This is the Unix philosophy. Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."
—Doug McIlroy

Most computer application programs can be thought of as software tools. If the only tool you have is a hammer, everything looks like a nail. The guy who writes letters in his spreadsheet program is a good example of this. Unix programs too are software tools. And Unix is a toolbox stuffed full of these tools. The more tools you have, the more you can do.

Two concepts in particular stand out that make the "toolbox" much more useful. The first is the idea of the filter.

The Filter

The concept of a filter is a key idea for anyone who wishes to use Unix effectively, but especially for the programmer. It is one that migrants from other operating systems may find new and unusual.

So what is a filter? At the most basic level, a filter is a program that accepts input, transforms it, and outputs the transformed data. The idea of the filter is closely associated with several ideas that are central features of Unix: standard input and output, input/output redirection, and pipes.

Standard input and output refer to default places from which a program will take input and to which it will write output respectively. The standard input (STDIN) for a program running interactively at the command line is the keyboard; the standard output (STDOUT), the terminal screen.

With input/output redirection, a program can take input or send output someplace other than standard input or output — to a file, for instance. Redirection of STDIN is accomplished using the < symbol, redirection of STDOUT by >.

The Pipe

The second idea is the pipe. The pipe (|) is a junction that allows us to connect the standard output of one program with the standard input of another. A moment's thought should make the usefulness of this when combined with filters quite obvious. We can build quite complex programs, on the command line or in a shell script, simply by stringing filters together.

The combination of filters and pipes is very powerful, because it allows you a) to break down tasks and b) to pick the best tool for tackling each task. Many jobs that would have to be handled in a programming language (Perl, for example) in another computing environment, can be done under Unix by stringing together a few simple filters on the command line. Even when a programming language must be used for a particularly complicated filter, you are still saving a lot of development effort through doing as much as possible using existing tools.

Executive Summary

Further Reading

I could go on, but the Unix Philosophy has been expounded in detail already by some of its most notable proponents. What I've written here should hopefully provide a concise summary. For further reading, you could do worse than start with two books by some Bell Labs luminaries: The Unix Programming Environment. and Software Tools. I should also mention Mike Garantz's The Unix Philosophy. This provides a useful foil to the other two books: shorter on examples and code, longer on the ideas behind them, and very much worth reading.

Here are some web resources:


[back to Linux, Unix, /etc] [Contact]



Vi Powered!

Copyright © 1995-2009 Paul Dunne,

Sponsored links (requires javascript):