Datasheet

❘

CHAPTER 1 THE HISTORY OF UNIX, GNU, AND LINUX

An early feature of Unix was the introduction of pipes — something that Doug McIlroy had been

thinking about for a few years and was implemented in Unix by Ken Thompson. Again, it took the

same notion of streamed serial data, but pipes introduced the idea of having

stdin and stdout,

through which the data would ﬂ ow. Similar things had been done before, and the concept is fairly

simple: One process creates output, which becomes input to another command. The Unix pipes method

introduced a concept that dramatically affected the design of the rest of the system.

Most commands have a ﬁ le argument as well, but existing commands were modiﬁ ed to default

to read from their “Standard Input” (

stdin) and “Standard Output” (stdout); the pipe can then

“stream” the data from one tool to another. This was a novel concept, and one that strongly deﬁ nes

the Unix shell; it makes the whole system a set of generically useful tools, as opposed to monolithic,

single-purpose applications. This has been summarized as “do one thing and do it well.” The GNU

toolchain was written to replace Unix while maintaining compatibility with Unix tools. The devel-

opers on the GNU project often took the opportunity presented by rewriting the tool to include

additional functionality, while still sticking to the “do one thing and do it well” philosophy.

The GNU project was started in 1983 by Richard Stallman, with the intention of

replacing proprietary commercial Unices with Free Software alternatives. GNU

had all but completed the task of replacing all of the userspace tools by the time

the Linux kernel project started in 1991. In fact, the GNU tools generally per-

form the same task at least as well as their original Unix equivalents, often pro-

viding extra useful features borne of experience in the real world. Independent

testing has shown that GNU tools can actually be more reliable than their tradi-

tional Unix equivalents (

http://www.gnu.org/software/reliability.html).

For example, the who command lists who is logged in to the system, one line per logged-in session.

The

wc command counts characters, words, and lines. Therefore, the following code will tell you

how many people are logged in:

who | wc -l

There is no need for the who tool to have an option to count the logged-in users because the generic

wc tool can do that already. This saves some small effort in who, but when that is applied across the

whole range of tools, including any new tools that might be written, a lot of effort and therefore

complexity, which means a greater likelihood of the introduction of additional bugs, is avoided.

When this is applied to more complicated tools, such as

grep or even more, the ﬂ exibility of the sys-

tem is increased with every added tool.

In the case of more, this is actually more tricky than it seems; ﬁ rst it has to ﬁ nd

out how many columns and rows are available. Again, there is a set of tools that

combine to provide this information. In this way, every tool in the chain can be

used by the other tools.

024485c01.indd 4024485c01.indd 4 7/26/11 8:31:57 AM7/26/11 8:31:57 AM