follows. The second part (Design) unfolds the principles of the Unix philosophy into more
specific advice about design and programming. The third part (Tools) focuses on the
software Unix provides for helping you solve problems. The fourth part (Community) is
about the human-to-human transactions and agreements that make the Unix culture so
effective at what it does.
Because this is a book about shared culture, the author never planned to write it alone. You
will notice that the text includes guest appearances by prominent Unix developers, the
shapers of the Unix tradition. The book went through an extended public review process
during which the author invited these luminaries to comment on and argue with the text.
Rather than submerging the results of that review process in the final version, these guests
were encouraged to speak with their own voices, amplifying and developing and even
disagreeing with the main line of the text.
This book is written using the editorial ‘we’ not to pretend omniscience but reflecting the
fact that it is an attempt to articulate the expertise of an entire community. One of the
‘guests’ will be the author himself, occasionally speaking in first person to convey a
reminiscence, a war story, or a personal opinion that is not necessarily reflective of the Unix
community at large.
Because this book is aimed at transmitting culture, it includes much more in the way of
history and folklore and asides than is normal for a technical book. Enjoy; these things, too,
are part of your education as a Unix programmer. No single one of the historical details is
vital, but the gestalt of them all is important. We think it makes a more interesting story this
way. More importantly, understanding where Unix came from and how it got the way it is
will help you develop an intuitive feel for the Unix style.
For the same reason, we refuse to write as if history is over. You will find an unusually large
number of references to the time of writing in this book. We do not wish to pretend that
current practice reflects some sort of timeless and perfectly logical outcome of preordained
destiny. References to time of writing are meant as an alert to the reader two or three or five
years hence that the associated statements of fact may have become dated and should be
double-checked.
Other things this book is not is neither a C tutorial, nor a guide to the Unix commands and
API. It is not a reference for sed or Yacc or Perl or Python. It's not a network programming
primer, nor an exhaustive guide to the mysteries of X. It's not a tour of Unix's internals and
architecture, either. There are other books that cover these specifics better, and this book will
point you at them as appropriate.