Unix编程艺术（前言）

Preface

前言

Unix is not so much an operating system as an oral history.

--NealStephenson

Unix与其说是一个操作系统，不如说是一部口述史。

―― 作者：NealStephenson

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.

本书涉及到很多知识，但主要是专业技术。它教你Unix开发的技术，这些技术是专家知道、但并没有意识到的。所以本书涉及到的技巧比较少，与大多数Unix书籍相比，本书更多的是共享文化――既包括外在和内在文化，也包括惯例和潜规则。它不是一本“怎样去做”的书，而是一本“为什么做”的书。

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.

“为什么做”有很大的实用价值，因为到目前为止，相当多的软件设计得很糟糕。它们大多设计得臃肿，难以维护，很难移植到新的平台，或者在进行功能扩展时其难度超出了最初的程序员的期望。我们希望本书的读者学会一些Unix设计的好的东西。

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.

本书分成四部分：来龙去脉，设计，工具 和 社群。第一部分（来龙去脉）讲述思想和历史，为后面的章节打基础。第二部分（设计）对原理和Unix思想进行了展开，讲述更详细的设计和实现的建议。第三部分（工具）聚焦在Unix提供的能够帮你解决问题的工具上。第四部分（社群）是关于人与人之间的交流和协议，这些使Unix文化更加有生气。

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.

由于本书是一本关于共享文化的书，我并不打算独自一人写它。你会发现它包括许多Unix开发者和Unix传统缔造者的观点。在我邀请大量的学者评论、讨论原文的期间，本书经过了一个长期的公共评审的过程。在本书最终版本并没有抛弃评审过程中的结果，来宾们畅所欲言，增强了、发展了原文的主线，当然也使原文的主线产生了一定的分歧。

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.

因为本书的目的是传输知识，除了是一本技术上的书，它还包含了一些历史和传说。这也是Unix程序员教育的一部分，充分享受它们吧。并不是其中每个历史资料是至关重要的，它们的有机整合却很重要。我认为，以这种方式可以创建一个更有趣的故事。更重要的，了解Unix的来龙去脉会发展你对Unix风格的直觉。

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.

另外，本书并不是一本C指南，也不是一本Unix命令和API的指南。它不是一本Sed ,Yacc，Perl或Python的参考，它不是网络初级编程，也不是一本神秘的X指南，它也不是一本对Unix体系结构入门的书。其他的书在这些细节上写得更好，这本书仅点到为止。

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.

超越这些技术细节，Unix文化有个不成文的工程惯例，在这个惯例的基础上已经发展了几百万人年的成就。这本书正式秉着这个惯例的理念写的。 并且把它的设计模式加进了你的工具包，这将帮助你成为更好的程序员和设计师。

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.

文化由人组成，学Unix文化的传统方式是从其他人身上学到或者靠传说的渗透。这本书并不是一本人与人之间的文化适应的替代品，而是允许你通过学习别人的经验上来加速你学习的过程。

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.

如果你是一个培养新手的Unix程序员，在争辩与其它的操作系统的优劣时，并且很难讲清Unix的好处，那么你就应该读这本书。

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.

如果你是一个C、C++或Java程序员，你有其他操作系统的经验并且准备转向基于Unix的程序设计，那么你应该读这本书。

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.

如果你具有Unix初级水平，并且希望在操作系统上达到中级水平，但是你几乎没有开发经验，并且你想学习在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.

如果你是一个领会到了Unix传统可能会教你很多东西的非Unix程序员，你应该读这本书。我们相信你是对的，并且Unix的思想对到其他的操作系统同样适用。所以较一般的Unix书而言我们更加重视非Unix环境（尤其是微软操作系统），并且当工具和个案研究变得轻松时，我们也这么说。

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.

如果你是一个系统构架师，你正在考虑主流市场或顶级应用的应用平台和实现策略，你应该读这本书。它帮有助于你理解作为一个开发平台Unix的力量和Unix以开源作为发展方法的魅力。

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 [Stevens92] is classic among explorations of the Unix API, and The Practice of

Programming [Kernighan-Pike99] is recommended reading for all C programmers (indeed for all

programmers in any language).

如果你正在寻找C语言编码的细节或者怎样使用Unix核心API，那么你不应该读这本书。关于这些主题有很多好书。《Unix环境高级编程》[Stevens92]是Unix API 书籍中的杰作，《编程实践》[Kernighan-Pike99]是所有C程序员的推荐读物（实际上是使用任何一种语言的程序员）。

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.

这本书既实用，而且富有哲学思想。有些部分是格言和总结，其他的则是Unix开发的详细个例研究。我们在一般的原理和概括讲解后举实例加以说明。例子并不是来源于玩具例子，而是我们每天用到的实际工作代码。

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.

这些有趣的例子对你学得一知半解的知识将是很好的巩固。理论上，在你读这本书的时候，应该在Unix系统的控制台旁，而且旁边还有web浏览器的帮助。任何Unix系统都可以，但是这些软件个例研究在Linux系统下会变得更适合。本书中的指示器要求你浏览并进行实践。这些指示器的介绍离主题远了些，但是并不会割裂本书的连续性。

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.

注意：当我们试图引用网址时，应该保持它是稳定的和可用的，然而事实上我们没有方法保证这一点。如果你发现一个链接不可用，根据常识可以用你喜欢的web搜索引擎查找。当我们在引用网址附近我们经常这样建议。

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 & Pike’s The Unix Programming Environment [Kernighan-Pike84] 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.

早期一些涉及这些领域的Unix开发者写的论文和书籍。Kernighan 和 Pike的《Unix编程环境》[Kernighan-Pike84]就是他们的杰出代表，将其视作经典最恰当不过了。但是今天它显得有点老，它并没有覆盖到Internet、万维网或解释语言的浪潮，例如Perl，Tcl 和 Python。

About halfway into the composition of this book, we learned of Mike Gancarz’s The Unix Philosophy

[Gancarz]. 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.

在本书中有一部分，我们学习了Mike Gancarz的书《Unix思想》[Gancarz]。这本在它涉及的范围里是相当优秀的，可惜它并没有尝试覆盖到我们认为应该提到的全部主题。但是作者对Unix设计模式中最简单的成型的、成功的例子的暗示，我们非常感激。

The Pragmatic Programmer [Hunt-Thomas] 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.

《程序员的修炼之道》[Hunt-Thomas]是一本关于好的设计习惯的书，它写得很诙谐，很博学。跟这本书相比，它在软件设计工艺上倾向的水平不同（更多的是编码，问题的高水平分割比较少）。作者的思想是Unix经验的产物，这是这本书优秀的补充。

The Practice of Programming [Kernighan-Pike99] covers some of the same ground as The Pragmatic

Programmer from a position deep within the Unix tradition.

《编程实践》[Kernighan-Pike99]覆盖了《程序员的修炼之道》的一些相同的Unix传统的深入研究。

Finally (and with admitted intent to provoke) we recommend Zen Flesh, Zen Bones [Reps-Senzaki], 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 addressing some ideas that turn out to be very important for software design but are otherwise very difficult to hold in the mind. Readers with religious attachments are invited to consider Zen not as a religion but as a therapeutic form of mental discipline—which, in its purest non-theistic forms, is exactly what Zen is.

最后(带有一定目的)，我们推荐《禅、肉体和尸体》 [Reps-Senzaki]，一个重要的宗教集合来源。这本书中零零散散的提到了禅，它们被包含在书中是因为他们提供的表达词汇很多在软件设计上非常重要，但是其他的很难把握。建议有宗教信仰的读者不要认为禅是一个宗教，而是一个纯无神论的精神医疗剂，这是它的真正所在。

Conventions Used in This Book

本书的约定

The term “UNIX” is technically and legally a trademark of The Open Group, and should formally be used only for operating systems which are certified to have passed The Open Group’s elaborate standards-conformance tests. In this book we use “Unix” in the looser sense widely current among programmers, to refer to any operating system (whether formally Unix-branded or not) that is either genetically descended from Bell Labs’s ancestral Unix code or written in close imitation of its descendants. In particular, Linux (from which we draw most of our examples) is a Unix under this definition.

术语UNIX是开源组织的合法商标，并且应该正规的仅仅用在被开源组织经过严格测试的操作系统中。在这本书里，当涉及到无论是贝尔实验室产生的原始Unix代码还是其后来的变种的操作系统（无论是否是正规的Unix商标）我们在一种比较宽松的环境里用Unix。特别说明，Linux（我们就是用它表述了很多例子）就符合这个定义。

This book employs the Unix manual page convention of tagging Unix facilities with a following manual section in parentheses, usually on first introduction when we want to emphasize that this is a Unix command. 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 5 is file formats and protocols, section 8 is system administration tools. Other sections vary among Unixes but are not cited in this book. For more, type man 1 man at your Unix shell prompt (older System V Unixes may require man –s 1 man).

这本书为了标签Unix方便，借用了Unix指南页并用圆括号表明，通常在我们第一次介绍我们强调这是一个Unix命名的时候。这样，例如，读“munger(1)”作为“munger”程序，在Unix手册的第一部分说明，如果Unix手册在你的系统上存在的话。第二部分是C系统调用，第三部分是C库调用，第五部分是文件格式和协议，第八部分是系统管理工具。其他的部分在Unixes之间变化，但是在本书中并没有引用。更多，在你的Unix系统下输入man 1 man shell命令（在更老的系统V Unixes上可能是man –s 1 man）。

Sometimes we mention a Unix application (such as Emacs, without a manual-section suffix and capitalized. This is a clue that the name actually represents a well-established family of Unix programs with essentially the same function, and we are discussing generic properties of all of them. Emacs, for example, includes xemacs.

有些时候我们谈到Unix应用（例如Emacs）没有没有手册段落后缀和大写起始字母。这是一个线索，名字确实代表了确定的Unix程序家族，本质上是相同的函数，并且我们讨论他们所有的属性。例如 Emacs包括xemacs。

At various points later in this book we refer to ‘old school’ and ‘new school’ methods. As with rap music, new-school starts about 1990. In this context, it’s associated with the rise of scripting languages, GUIs, open-source Unixes, and the Web. Old-school refers to the pre-1990 (and especially pre-1985) world of expensive (shared) computers, proprietary Unixes, scripting in shell, and C everywhere. This difference is worth pointing out because cheaper and less memory constrained machines have wrought some significant changes on the Unix programming style.

本书中，在各种不同的点后我们涉及“老学校”和“新学校”方法。像快板歌一样，“新学校”开始于大约1990年。在这个过程中，随着脚本语言、GUIs、开源Unixes和Web的壮大，与他们相关联。“老学校”涉及到1990年之前(尤其是1985年之前)昂贵的电脑、所有的Unixes、shell中的脚本 和 无处不在的C。值得指出的不同点是便宜和更小的内存促进了Unix程序风格的一些重要的改变。

Our Case Studies

我们的个例研究

A lot of books on programming rely on toy examples constructed specifically to prove a point. This one won’t. Our case studies will be real, pre-existing pieces of software that are in production use every day. Here are some of the major ones:

许多程序设计的书依靠构造玩具例子来支持他的论点，这本书没有这么做。我们的个例研究将是真正的、我们在用的软件作品中的部分。这儿列出了主要的几个。

cdrtools/xcdroast These two separate projects are usually used together. The cdrtools package is a set of CLI tools for writing CD-ROMs; Web search for “cdrtools”. The xcdroast application is a GUI front end for cdrtools; see the xcdroast project site [http://www.xcdroast.org/].

cdrtools/xcdroast 这2个相关的项目通常一起使用。cdrtools工具包是一系列CLI关于写CD-ROM的CLI工具集；通过网络搜索“cdrtools”。xcdroast应用是一个使用cdrtools的GUI前端；参考xcdroast工程站点[http://www.xcdroast.org/]。

Fetchmail The fetchmail program retrieves mail from remote-mail servers using the POP3 or IMAP post-office protocols. See the fetchmail home page [http://www.catb.org/~esr/fetchmail] (or search for “fetchmail” on the Web).

Fetchmail Fetchmail程序利用POP3和IMAP邮局协议从远端邮件服务器收回mail.请查看Fetchmail的主页。[http://www.catb.org/~esr/fetchmail]（或在网上查找“fetchmail”）

GIMP The GIMP (GNU Image Manipulation Program) is a full-featured paint, draw, and image-manipulation program that can edit a huge variety of graphical formats in sophisticated ways. Sources are available from the GIMP home page [http://www.gimp.org/] (or search for "GIMP" on the Web).

GIMP GIMP（GNU图形操作程序）是一个全功能的绘画、图形处理程序，它可以神秘的处理各种各样的图形格式。可以从GIMP主页上得到源代码。[http://www.gimp.org/]（或者在网上查找“GIMP”）

Mutt The mutt mail user agent is the current best-of-breed among text based Unix electronic mail agents, with notably good support for MIME (Multipurpose Internet Mail Extensions) and the use of privacy aids such as PGP (Pretty Good Privacy) and GPG (GNU Privacy Guard). Source code and executable binaries are available at the Mutt project site [http://www.mutt.org].

Mutt Mutt 邮件用户代理是当前最好的基于文本的Unix电子邮件代理，对MIME（多用途网络邮件扩展）有相当好的支持，并且带有隐私帮助，例如PGP（Pretty Good Privacy）和GPG（GNU Privacy Guard）。查看源码和可执行二进制文件可以上Mutt的网站[http://www.mutt.org]。

xmlto The xmlto command renders DocBook and other XML documents in various output formats, including HTML and text and PostScript. For sources and documentation, see the xmlto project site [http://cyberelk.net/tim/xmlto/].

xmlto xmlto 命令使 DocBook 和 其他的文档 呈现出各种输出格式，包括 HTML、文本 和 PostScript。查看源代码和文档，可以上xmlto的网站[http://cyberelk.net/tim/xmlto/]。

To minimize the amount of code the user needs to read to understand the examples, we have tried to choose case studies that can be used more than once, ideally to illustrate several different design principles and practices. For this same reason, many of the examples are from my projects. No claim that these are the best possible ones is implied, merely that I find them sufficiently familiar to be useful for multiple expository purposes.

为了使读者需要读懂的例子尽量少，我们尝试着把个例研究不止一次使用，完美的举出几个不同的设计原理。相同的理由，这些例子很多源自我自己的程序。如果没有特别指明就默认是的。只不过是因为我发现它们很适合于说明不同的目的。

Author’s Acknowledgements

作者的感谢

The guest contributors (Ken Arnold, Steven M. Bellovin, Stuart Feldman, Jim Gettys, Steve Johnson, Brian Kernighan, David Korn, Mike Lesk, Doug McIlroy, Marshall Kirk McKusick, Keith Packard, Henry Spencer, and Ken Thompson) added a great deal of value to this book. Doug McIlroy, in particular, went far beyond the call of duty in the thoroughness of his critique and the depth of his contributions, displaying the same care and dedication to excellence which he brought to managing the original Unix research group thirty years ago.

来宾们（Ken Arnold, Steven M. Bellovin, Stuart Feldman, Jim Gettys, Steve Johnson, Brian Kernighan, David Korn, Mike Lesk, Doug McIlroy, Marshall Kirk McKusick, Keith Packard, Henry Spencer, and Ken Thompson）为这本书提供了很多有价值的部分。尤其是Doug McIlroy，完全超出了批评和深度贡献的职责，显示出了他的关心程度如同三十年前对原始的Unix研究组的优秀的贡献一样。

Special thanks go to Rob Landley and to my wife Catherine Raymond, both of whom delivered intensive line-by-line critiques of manuscript drafts. Rob’s insightful and attentive commentary actually inspired more than one entire chapter in the final manuscript, and he had a lot to do with its present organization and range; if he had written all the text he pushed me to improve, I would have to call him a co-author. Cathy was my test audience representing non-technical readers; to the extent this book is accessible to people who aren’t already programmers, that’s largely her doing.

尤其要感谢Rob Landley和我的妻子Catherine Raymond，他们都对手稿逐行进行了评论。Rob的深刻间接确实使手稿的最后变得更有灵感，并且它在他目前的组织和范围有很多需要做，如果他写下所有的要我改进的文字，我可以称他为半个作者。Cathy是作为非技术读者，是我的测试观众。这本书在内容上对非程序员的可读性，很大程度上源于她的努力。

This book benefited from discussions with many other people over the five years it took me to write it. Mark M. Miller helped me achieve enlightenment about threads. John Cowan supplied some insights about interface design patterns and drafted the case studies of wily and VM/CMS, and Jef Raskin showed me where the Rule of Least Surprise comes from. The UIUC System Architecture Group contributed useful feedback on early chapters. The sections on What Unix Gets Wrong and Flexibility in Depth were directly inspired by their review. Russell J. Nelson contributed the material on Bernstein chaining in Chapter 7. Jay Maynard contributed most of the material in the MVS case study in Chapter 3. Les Hatton provided many helpful comments on the Languages chapter and motivated the portion of Chapter 4 on Optimal Module Size. David A. Wheeler contributed many perceptive criticisms and some case-study material, especially in the Design part. Russ Cox helped develop the survey of Plan 9. Dennis Ritchie corrected me on some historical points about C.

这本书得益于我和与很多人的讨论，他花了我不止五年时间来写它。Mark M. Miller帮我完成思路的启迪。John Cowan提供了接口设计模式的洞察力，起草了wily和VM/CMS的个例研究。Jef Raskin告诉我Rule of Least Surprise来自哪里。UIUC系统构架组对早期的章节提供了有用的反馈。（What Unix Gets Wrong and Flexibility in Depth）部分直接来源于他们评审的灵感。Russell J. Nelson对第七章的Bernstein chaining提供了很多材料。Jay Maynard提供了第三章MVS个里研究的绝大部分材料。Les Hatton给Languages章节提供了学多有用的评论，激发了第四章Optimal Module Size的一部分。David A. Wheeler提供了许多有意义的批评和一些个例研究材料，尤其是在设计（Design）部分。Russ Cox发展了survey of Plan 9。Dennis Ritchie纠正了我的一些C的历史的错误。

Hundreds of Unix programmers, far too many to list here, contributed advice and comments during the book’s public review period between January and June of 2003. As always, I found the process of open peer review over the Web both intensely challenging and intensely rewarding. Also as always, responsibility for any errors in the resulting work remains my own. 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 the book 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, my approach has certainly been influenced by Christopher Alexander’s work (especially The Timeless Way of Building and A Pattern Language, and 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 use Alexander’s insights to talk about software design at a high level without merely uttering vague and useless generalities. Interested readers should see Design Patterns: Elements of Reusable Object-Oriented Software [GangOfFour] for an introduction to design patterns.

数以千计的Unix程序员，由于太多这儿无法罗列。在2003年1月到6月的公共评审阶段它们贡献了很多有用的建议和评论。所以，我发现放在web上进行公共评审是既有挑战也有丰厚的回报的。而且，对结果工作中遗留的任何错误的责任。这本书的说明风格和本书一些涉及项已经被涉及模式运动所影响。确实，我犹豫着是否这本书的名字应该是《Unix设计模式》。我并没有那么做，我并不盲从这场运动的教条，并且我认为确实没必要接受他的正式的设备和他的文化包袱。然而，我的接近当然被Christopher Alexander的工作所影响。（尤其是《建筑的永恒方法》和《一种模式语言》，我归功于“四人帮”和其他的大量指引我可能利用Alexander的洞察力在几乎没有含糊的高水平的软件设计。有兴趣的读者可以看看《设计模式》和《可重用面向对象软件原理》[GangOfFour]中对涉及模式的介绍。

The title of this book is, of course, a reference to Donald Knuth’s The Art of Computer Programming. While not specifically associated with the Unix tradition, Knuth has been an influence on us all. Editors with vision and imagination aren’t as common as they should be. Mark Taub is one; he saw merit in a stalled project and skillfully nudged me into finishing it. Copy editors with a good ear for prose style and enough ability to improve writing that isn’t like theirs are even less common, but Mary Lou Nohr makes that grade. Jerry Votta seized on my concept for the cover and made it look better than I had imagined. The whole crew at Prentice-Hall gets high marks for making the editorial and production process as painless as possible, and for cheerfully accommodating my control-freak tendencies not just over the text but deep into the details of the book’s visual design, art, and marketing.

这本书的标题当然是参考了Donald Knuth的《计算机编程艺术》。然而于Unix传统关联不是很大，Knuth已经对我们有很大的影响。编辑的想象并不是他们应该的那么普通。Mark Taub是其中的一个，她看到一个中断的工程的价值并且说服我去完成它。有散文风格和足够能力提高写作的拷贝编辑们不是像他们那样less common，但是Mary Lou Nohr做出了成绩。Jerry Votta抓住了我的封面的核心，并且它比我想象的要好。Prentice-Hall的全体人员在编辑和出版过程得到了很高的评价，在我的文本而不是书的可视化设计、艺术和市场的详细内容的也有很高的评价。

Chapter 1. Philosophy

第一章 思想

Philosophy Matters

思想问题

Those who do not understand Unix are condemned to reinvent it, poorly.

--HenrySpencer

Usenet signature, November 1987

那些不懂Unix的人往往可怜的认为是对它的重复发明。

-- HenrySpencer ，1987.11

Culture? What Culture?

文化？什么文化？

This is a book about Unix programming, but in it we’re going to toss around the words ‘culture’, ‘art’, and ‘philosophy’ a lot. If you are not a programmer, or you are a programmer who has had little contact with the Unix world, this may seem strange. But Unix has a culture; it has a distinctive art of programming; and it carries with it a powerful design philosophy. Understanding these traditions will help you build better software, even if you’re developing for a non-Unix platform. Every branch of engineering and design has technical cultures. In most kinds of engineering, the unwritten traditions of the field are parts of a working practitioner’s education as important as (and, as experience grows, often more important than) the official handbooks and textbooks. Senior engineers develop huge bodies of implicit knowledge, which they pass to their juniors by (as Zen Buddhists put it) “a special transmission, outside the scriptures”.

这是一本Unix编程的书，但是在本书中我们并不打算围绕“文化”、“艺术”和“思想”等讨论很多。如果你还不是一个程序员，或者你是一个很少接触Unix世界的程序员，可能会感到有些奇怪。但是Unix有一种文化，它有与众不同的编程艺术，并且它承载了一种强大的设计思想。懂得这些传统将帮助你构件更好的软件，甚至你正在一个非Unix平台下开发软件。每一个工程设计的分支都有技术文化。在很多种类的工程中，该领域不成文的规定是从业者的学习范畴，这个同正式的手册和课本同样重要（并且随着经验的增长，越来越重要）。高级工程师发展了大量被证实为正确的知识，这些知识靠（正如Zen Buddhists说的）“特殊的方式，在文档之外的”这种方式传给后来的人。

Software engineering is generally an exception to this rule; technology has changed so rapidly, software environments have come and gone so quickly, that technical cultures have been weak and ephemeral. There are, however, exceptions to this exception. A very few software technologies have proved durable enough to evolve strong technical cultures, distinctive arts, and an associated design philosophy transmitted across generations of engineers.

软件工程逐渐成为这个规定的例外。技术更新得如此快，软件环境来得快，去的也快，技术文化变得微弱和短暂的。然而，也有这个例外的例外。有些软件技术被证实是发展的足够耐用的以致进化出了很强的科技文化、与众不同的艺术，相关联的设计思想也通过工程师的产生而传播。

The Unix culture is one of these. The Internet culture is another — or, in the twenty-first century, arguably the same one. The two have grown increasingly difficult to separate since the early 1980s, and in this book we won’t try particularly hard.

Unix文化就是其中的一个。Internet文化是另外的一个，或者说，在二十一世纪，可以论证相同的一个。自从20世纪80年代以来，这两个的发展已经日益难以分开，在本书中，我们也不想努力的去分开。

The Durability of Unix

Unix的持久力

Unix was born in 1969 and has been in continuous production use ever since. That’s several geologic eras by computer-industry standards — older than the PC or workstations or microprocessors or even video display terminals, and contemporaneous with the first semiconductor memories. Of all production timesharing systems today, only IBM’s VM/CMS can claim to have existed longer, and Unix machines have provided hundreds of thousands of times more service hours; indeed, Unix has probably supported more computing than all other timesharing systems put together.

自从1969年Unix诞生以来，一直都在不断的研究利用中。有几个地理区域靠计算机工业标准――比PC或工作站或微处理器或Video显示终端更早，并且随着最早的半导体存储器。在所有的产品中，今天的时间共享系统，只有IBM的VM/CMS可以称为是存在更长，并且Unix机器已经提供了百万倍的服务小时。确实，Unix提供的服务比其他时间共享系统提供的服务时间加起来还要多。

Unix has found use on a wider variety of machines than any other operating system can claim. From supercomputers to handhelds and embedded networking hardware, through workstations and servers and PCs and minicomputers, Unix has probably seen more architectures and more odd hardware than any three other operating systems combined.

Unix已经在更广阔的机器上建立了使用，这比其他任何操作系统宣称的要多。从超级计算机到手持设备和嵌入式网络硬件，通过工作站和PC和微机，Unix很可能看见了更多的工艺和不固定的硬件，这很有可能比其它的人以三种操作系统联合起来还要多。

Unix has supported a mind-bogglingly wide spectrum of uses. No other operating system has shone simultaneously as a research vehicle, a friendly host for technical custom applications, a platform for commercial-off-the-shelf business software, and a vital component technology of the Internet.

Unix已经提供了一个mind-bogglingly 范围的使用。没有哪个其他的操作系统有这样的研究手段，为技术定制应用程序的主机，商业软件平台，和 Internet技术的重要组件。

Confident predictions that Unix would wither away, or be crowded out by other operating systems, have been made yearly since its infancy. And yet Unix, in its present-day avatars as Linux and BSD and Solaris and MacOS X and half a dozen other variants, seems stronger than ever today. Robert Metcalf [the inventor of Ethernet] says that if something comes along to replace Ethernet, it will be called “Ethernet”, so therefore Ethernet will never die.

自信的语言，自从Unix产生的幼年开始，Unix终究会枯萎，或者被其他的操作系统所排挤。但是，Unix，和他的具体存在形式，如Linux、BSD、Solaris、MacOS X 和其他半打其他的操作系统，看起来比曾经的任何时候都要健壮，Robert Metcalf（以太网的发明者）说如果某个东西出来了并代替了以太网，它将叫做“以太网”，所以说以太网将不会灭亡。

4 Unix has already undergone several such transformations.

—KenThompson

Unix已经经受了各种不同的转变。

---- KenThompson

At least one of Unix’s central technologies — the C language — has been widely naturalized elsewhere. Indeed it is now hard to imagine doing software engineering without C as a ubiquitous common language of systems programming. Unix also introduced both the now-ubiquitous treeshaped file namespace with directory nodes and the pipeline for connecting programs.

至少Unix核心技术之一C语言――已经被广泛的移植到其他地方。确实作为一个广泛存在系统编程语言，很难想象软件工程没有了C会怎样。Unix也即介绍了代目录节点的树形文件名字空间和连接程序的管道。

Unix’s durability and adaptability have been nothing short of astonishing. Other technologies have come and gone like mayflies. Machines have increased a thousand fold in power, languages have mutated, industry practice has gone through multiple revolutions — and Unix hangs in there, still producing, still paying the bills, and still commanding loyalty from many of the best and brightest software technologists on the planet.

Unix的持久力和适应性已经没有什么可惊奇的了。其他的科技像飞蝼蛄一样产生了，又消失了。机器的效率已经增长了一千倍，语言也便以了，工业实践也经历很多革命-----并且Unix仍然站在那儿，仍然在生产，仍然在支付账单，仍然在指挥着来自这个行星上的最好的和最健壮的软件科技的忠诚。

One of the many consequences of the exponential power-versus-time curve in computing, and the corresponding pace of software development, is that 50% of what one knows becomes obsolete over every 18 months. Unix does not abolish this phenomenon, but does do a good job of containing it.

许多后来在计算上的效率和时间的指数增长曲线之一，和相应的软件开发速度，一个人知道的东西有18个月就会有一半变得没有用。Unix并没有飞出这种现象，而是在其中做一个很好的工作。

There’s a bedrock of unchanging basics—languages, system calls, and tool invocations—that one can actually keep using for years, even decades. Elsewhere it is impossible to predict what will be stable; even entire operating systems cycle out of use. Under Unix, there is a fairly sharp distinction between transient knowledge and lasting knowledge, and one can know ahead of time (with about 90% certainty) which category something is likely to fall in when one learns it. Thus the loyalty Unix commands.

有不改变的根基――语言、系统调用和工具，一个人的确可以用好几年，甚至几十年。在别处，不可能预测什么是稳固的，甚至语言和永恒的知识，一个人知道超前（确定大约90%）某种种别的事情很有可能导致学习它。这就是Unix命令的忠诚度。

Much of Unix’s stability and success has to be attributed to its inherent strengths, to design decisions Ken Thompson, Dennis Ritchie, Brian Kernighan, Doug McIlroy, Rob Pike and other early Unix developers made back at the beginning; decisions that have been proven sound over and over. But just as much is due to the design philosophy, art of programming, and technical culture that grew up around Unix in the early days. This tradition has continuously and successfully propagated itself in symbiosis with Unix ever since.

Unix的稳定性和成功归功于它内在的力量，归功于它的果断的设计者，Ken Thompson, Dennis Ritchie, Brian Kernighan, Doug McIlroy, Rob Pike和其他早期的Unix开发者。决定已经被证实了一次又一次。正如他的设计思想、编程艺术和 在早期伴随着Unix成长的技术文化。Unix传统在与Unix合作中已经不断的，成功的宣传它自己。

1．The three and a half decades between 1969 and 2003 is a long time. Going by the historical trend curve in number of Unix sites during that period, probably somewhere upwards of fifty million man-years have been plowed into Unix development worldwide.

1．1969年到2003年近35年是一个很长的时间。在这个期间内随着Unix站点数目的历史曲线图的变化，全世界极有可能有五千万人年的开发量涌向Unix开发。

2．This particular footnote is dedicated to Terry Pratchett, whose use of footnotes is quite...inspiring.

为这个特别的脚注做出贡献的Terry Pratchett，他对脚注的利用是非常受人鼓舞的。

3An appreciation of Alexander’s work, with links to on-line versions of significant portions, may be found at Some Notes on Christopher Alexander [http://www.math.utsa.edu/sphere/salingar/Chris.text.html].

3．非常感谢Alexander对在线连接翻译的部分重要工作，你可以在这个网站Christopher Alexander [http://www.math.utsa.edu/sphere/salingar/Chris.text.html] 找到一些笔记.

4In fact, Ethernet has already been replaced by a different technology with the same name — twice. Once when coax was replaced with twisted pair, and a second time when gigabit Ethernet came in.

事实上，以太网已经被相同的科技代替了两次。第一次是coax被双绞线对代替，第二次是当gigabit介入。