Unix ranks among the great engineering accomplishments of the last half of the twentieth century, and its heir--Linux--seems already imposing and still on its way to achieving its full potential. Eric S. Raymond argues in The Art of UNIX Programming that the excellence of Unix derives as much from the fact that it was (and continues to be) a community effort as from the fact that a lot of smart people have worked to design and build it. Raymond, best known as the author of the open-source manifesto The Cathedral and the Bazaar, says in his preface that this is a "why-to" book, rather than a "how-to" book. It aims to show new Unix programmers why they should work under the old "hacker ethic"--embracing the principles of good software design for its own sake and of code-sharing. That said, a great deal of valuable practical information appears in this book. Very little of it is in the form of code; most of the practical material takes the form of case studies and discussions of aspects of Unix, all aimed at determining why particular design characteristics are good. In many cases, the people who did the work in the first place make guest appearances and explain their thinking--an invaluable resource. This book is for the deep-thinking software developer in Unix (and perhaps Linux in particular). It shows how to fit into the long and noble tradition, and how to make the software work right. --David Wall Topics covered: Why Unix (the term being defined to include Linux) is the way it is, and the people who made it that way. Commentary from Ken Thompson, Steve Johnson, Brian Kernighan, and David Korn enables readers to understand the thought processes of the creators of Unix.Preface Unix is not so much an operating system as an oral history. -;Neal Stephenson 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 therefore less about technicalia and more about shared culture than most Unix books -; both explicit and implicit culture, both conscious and unconscious traditions. It is not a 'how-to' book, it is a 'why-to' book. The why-to has great practical importance, because far too much software is poorly designed. Much of it suffers from bloat, is exceedingly hard to maintain, and is too difficult to port to new platforms or extend in ways the original programmers didn't anticipate. These problems are symptoms of bad design. We hope that readers of this book will learn something of what Unix has to teach about good design. This book is divided into four parts: Context, Design, Tools, and Community. The first part (Context) is philosophy and history, to help provide foundation and motivation for what follows. The second part (Design) unfolds the principles of the Unix philosophy into more specific advice about design and implementation. 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, I 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 I 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. In this book, when I use the editorial 'we' it is not to pretend omniscience but to reflect the fact that it attempts to articulate the expertise of an entire community. 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. Other books cover these specifics better, and this book points 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-years1 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. Cultures consist of people, and the traditional way to learn Unix culture is from other people and through the folklore, by osmosis. This book is not a substitute for person-to-person acculturation, but it can help accelerate the process by allowing you to tap the experience of others. Who Should Read This Book You should read this book if you are an experienced Unix programmer who is often in the position of either educating novice programmers or debating partisans of other operating systems, and you find it hard to articulate the benefits of the Unix approach. You should read this book if you are a C, C++, or Java programmer with experience on other operating systems and you are about to start a Unix-based project. You should read this book if you are a 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 philosophy 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 say so. You should read this book if you are an application architect considering platforms or implementation strategies for a major general-market or vertical application. It will help you understand the strengths of Unix as a development platform, and of the Unix tradition of open source as a development method. You should not read this book if what you are looking for is the details of C coding or how to use the Unix kernel API. There are many good books on these topics; Advanced Programming in the Unix Environment is classic among explorations of the Unix API, and The Practice of Programming is recommended reading for all C programmers (indeed for all programmers in any language). How to Use This Book 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. References are usually by author name. Numbered footnotes are for URLs that would intrude on the text or that we suspect might be perishable; also for asides, war stories, and jokes.2 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. Related References Some famous papers and a few books by Unix's early developers have mined this territory before. Kernighan and Pike's The Unix Programming Environment stands out among these and is rightly considered a classic. But today it shows its age a bit; it doesn't cover the Internet, and the World Wide Web or the new wave of interpreted languages like Perl, Tcl, and Python. About halfway into the composition of this book, we learned of Mike Gancarz's The Unix Philosophy . This book is excellent within its range, but did not attempt to cover the full spectrum of topics we felt needed to be addressed. Nevertheless we are grateful to the author for the reminder that the very simplest Unix design patterns have been the most persistent and successful ones. The Pragmatic Programmer is a witty and wise disquisition on good design practice pitched at a slightly different level of the software-design craft (more about coding, less about higher-level partitioning of problems) than this book. The authors' philosophy is an outgrowth of Unix experience, and it is an excellent complement to this book. The Practice of Programming covers some of the same ground as The Pragmatic Programmer from a position deep within the Unix tradition. Finally (and with admitted intent to provoke) we recommend Zen Flesh, Zen Bones , an important collection of Zen Buddhist primary sources. References to Zen are scattered throughout this book. They are included because Zen provides a vocabulary for a...
|
