In Memoriam Linuxlots (http://www.linuxlots.com/~dunne), 1999 -- 2011, R.I.P.

You are here: http://dunne.freeshell.org//command_line.html

Go to: index | blog | contact


In The Beginning Was The Command Line

It actually arrived some time after the beginning, but the phrase is too good to let go (Neil Stephenson coined it). Mostly, "the command line" means the Unix shell, though some die-hards still use COMMAND.COM.

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 so 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.

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.


To most people, "the Internet" means "the Web" i.e. the collection of sites using the http and https protocols to "serve" "content". Nowadays, the WWW is normally seen through the dark glass of a graphical browser, but text-mode web browsers can be launched from the command line too: lynx and links are personal favourites. Google (and a myriad other once-popular search engines) can be used from the command line too.

telnet.org gives access to what one might style the command line Internet.

The old tradition of free shell accounts has not quite died out. Here are some places:


Viewable with any browser

This page was brought to you by ksh, vi, m4, sed & make, courtesy of openbsd.
Last changed: Sun Mar 3 11:54:02 CET 2019