The Art of Unix Programming (Addison-Wesley Professional Computing) [Englisch] [Taschenbuch]

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.

The finer points of UNIX programming are explored by the author of "The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary."

The Art of UNIX Programming poses the belief that understanding the unwritten UNIX engineering tradition and mastering its design patterns will help programmers of all stripes to become better programmers. This book attempts to capture the engineering wisdom and design philosophy of the UNIX, Linux, and Open Source software development community as it has evolved over the past three decades, and as it is applied today by the most experienced programmers. Eric Raymond offers the next generation of "hackers" the unique opportunity to learn the connection between UNIX philosophy and practice through careful case studies of the very best UNIX/Linux programs.

"Reading this book has filled a gap in my education. I feel a sense of completion, understand that UNIX is really a style of community. Now I get it, at least I get it one level deeper than I ever did before. This book came at a perfect moment for me, a moment when I shifted from visualizing programs as things to programs as the shadows cast by communities. From this perspective, Eric makes UNIX make perfect sense."
--Kent Beck, author of Extreme Programming Explained, Test Driven Development, and Contributing to Eclipse

"A delightful, fascinating read, and the lessons in problem-solvng are essential to every programmer, on any OS."
--Bruce Eckel, author of Thinking in Java and Thinking in C++

Writing better software: 30 years of UNIX development wisdom

In this book, five years in the making, the author encapsulates three decades of unwritten, hard-won software engineering wisdom. Raymond brings together for the first time the philosophy, design patterns, tools, culture, and traditions that make UNIX home to the world's best and most innovative software, and shows how these are carried forward in Linux and today's open-source movement. Using examples from leading open-source projects, he shows UNIX and Linux programmers how to apply this wisdom in building software that's more elegant, more portable, more reusable, and longer-lived.

Raymond incorporates commentary from thirteen UNIX pioneers:

• Ken Thompson, the inventor of UNIX.
• Ken Arnold, part of the group that created the 4BSD UNIX releases and co-author of The Java Programming Language.
• Steven M. Bellovin, co-creator of Usenet and co-author of Firewalls and Internet Security.
• Stuart Feldman, a member of the Bell Labs UNIX development group and the author of make and f77.
• Jim Gettys and Keith Packard, principal architects of the X windowing system.
• Steve Johnson, author of yacc and of the Portable C Compiler.
• Brian Kernighan, co-author of The C Programming Language, The UNIX Programming Environment, The Practice of Programming, and of the awk programming language.
• David Korn, creator of the korn shell and author of The New Korn Shell Command and Programming Language.
• Mike Lesk, a member of the Bell Labs development group and author of the ms macro package, the tbl and refer tools,lex and UUCP.
• Doug McIlroy, Director of the Bell Labs research group where UNIX was born and inventor of the UNIX pipe.
• Marshall Kirk McKusick, developer of the 4.2BSD fast filesystem and a leader of the 4.3BSD and 4.4BSD teams.
• Henry Spencer, a leader among early UNIX developers, who created getopt, the first open-source string library, and a regular-expression engine used in 4.4BSD.

ERIC S. RAYMOND has been a Unix developer since 1982. Known as the resident anthropologist and roving ambassador of the open-source community, he wrote the movement's manifesto in The Cathedral and the Bazaar and is the editor of The New Hacker's Dictionary.

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-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.

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...