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 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.
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 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.
Here are some web resources:
[back to Linux, Unix, /etc] [Contact]
Copyright © 1995-2009
Paul Dunne,
Sponsored links (requires javascript):