This book is both practical and philosophical. Some parts are
aphoristic and general, others will examine specific case studies in
Unix development. We will precede or follow general principles and
aphorisms with examples that illustrate them: examples drawn not from
toy demonstration programs but rather from real working code that is
in use every day.
We have deliberately avoided filling the book with lots of code
or specification-file examples, even though in many places this
might have made it easier to write (and in some places perhaps
easier to read!). Most books about programming give too many
low-level details and examples, but fail at giving the reader a
high-level feel for what is really going on. In this book, we
prefer to err in the opposite direction.
Therefore, while you will often be invited to read code and
specification files, relatively few are actually included in the book.
Instead, we point you at examples on the Web.
Absorbing these examples will help solidify the principles you
learn into semi-instinctive working knowledge. Ideally, you should
read this book near the console of a running Unix system, with a Web
browser handy. Any Unix will do, but the software case studies are
more likely to be preinstalled and immediately available for
inspection on a Linux system. The pointers in the book are invitations
to browse and experiment. Introduction of these pointers is paced so
that wandering off to explore for a while won't break up exposition
that has to be continuous.
Note: While we have made every effort to cite URLs that should
remain stable and usable, there is no way we can guarantee this. If
you find that a cited link has gone stale, use common sense and do
a phrase search with your favorite Web search engine. Where possible
we suggest ways to do this near the URLs we cite.
Most abbreviations used in this book are expanded at first use.
For convenience, we have also provided a glossary in an appendix.
To make this book more accessible to less technical readers, we
invited some non-programmers to read it and identify terms that seemed
both obscure and necessary to the flow of exposition. We also use
footnotes for definitions of elementary terms that an experienced
programmer is unlikely to need.