There is a vast difference between knowledge and expertise. Knowledge lets you deduce the right thing to do; expertise makes the right thing a reflex, hardly requiring conscious thought at all.
This book has a lot of knowledge in it, but it is mainly about expertise. It is going to try to teach you the things about Unix development that Unix experts know, but aren't aware that they know. It is not a ``how-to'' book, it is ``why-to'' book.
This book is not a C tutorial, nor a guide to the Unix commands and API. It's not a reference for Yacc or Perl. 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.
Beyond all these technical specifics, the Unix culture has an unwritten engineering tradition that has developed over literally millions of man-years of skilled effort. This book is written in the belief that understanding that tradition, and adding its design patterns to your toolkit, will help you become a better programmer and designer.
This book is not a substitute for experience. But it should accelerate your learning process by allowing you to tap the experience of others.
You should read this book if you are an Unix user with novice-level up to middle-level skills in the operating system, but little development experience, and want to learn how to design software effectively under Unix.
You should read this book if you are a non-Unix programmer who has figured out that the Unix tradition might have something to teach you. We believe you're right, and that the Unix philosopy can be exported to other operating systems. So we will pay more attention to non-Unix environments (especially Microsoft operating systems) than is usual in a Unix book; and when tools and case studies are portable, we'll say so.
You should read this book if you are an application architect considering platforms or implementation strategies for a major merchant-market or vertical application.
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 run to 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, almost none are actually included in the book. Instead, we'll point you at examples on the Web.
All the code referenced in this book is available on-line, in open source, over the Internet. Use that resource! The case studies we choose are exemplars. You'll notice that some of these exemplars come up repeatedly, as case studies from different angles. This is deliberate; it is intended to reduce the amount of code and documentation you have to read in order to observe the entire range of design patterns we discuss.
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 Linux system, with a web browser handy. 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 will 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 keyword search with Alta Vista or Yahoo or Google. Where possible we suggest ways to do this near the URLs we cite.
About halfway into the composition of this book, I learned of Mike Gancarz's The Unix Philosophy [TUP]. This book is excellent within its range, but did not attempt to cover the full spectrum of topics which I felt needed to be addressed. Nevertheless, I'm grateful to the author for reminding me that the very simplest Unix design patterns have been the most persistent and successful ones.
This book employs the Unix manual page convention of tagging Unix facilities with a following manual section in parentheses. Thus, for example, read ``munger(1)'' as ``the `munger' program, which will be documented in section 1 (user tools) of the Unix manual pages, if it's present on your system.'' Section 2 is C system calls, section 3 is C library calls, section 8 is system administration tools. Other sections vary between Unixes but are not cited in this book.
Bibliography entries are cited in square brackets and will be found at the end of each chapter unless specifically noted otherwise.
The expository style and some of the concerns of this book have been influenced by the design patterns movement; indeed, I flirted with the idea of titling it "Unix Design Patterns". I didn't, because I disagree with some of the implicit central dogmas of the movement and don't feel the need to use all its formal apparatus or accept its cultural baggage. Nevertheless, I owe the Gang of Four and other members of their school a large debt of gratitude for showing me how it is possible to talk about design at a high level without merely uttering vague and useless generalities. Interested readers should see [DP] for an introduction to design patterns.