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.
知识和专家经验（expertise）有很大的区别。根据知识，可以推断出该做的正确的事；从专家经验出发，可以反射般地得到正确的事，几乎都不需要有意识的思考。
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专家知道他们，但却没有意识到他们已经知道。从而，与大多数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程序员应该受到的教育的一部分。任何单独的历史事件都不重要，但他们的“格”（gestalt, 结构或形态，其构成因素并不是各组成部分间的简单相加，而是一种完整的结构或形式——译者注）却是重要的。我们认为，这样处理会使故事有趣许多。更重要的是，理解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[1] 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文化有个不成文的工程传统，这是经由熟练技术人员数百万人年[1]的努力而形成的传统。写作本书，是相信一旦你理解了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环境（尤其是Mircrosoft操作系统）的着墨稍多；一旦工具和案例研究是可移植的，我们将指出来。
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环境高级编程》（Advanced Programming in the Unix Environment）[Stevens92]就是探索Unix API的经典，还有推荐所有C程序员阅读的《程序设计实践》（The Practice of Programming）[Kernighan-Pike99]（实际上，推荐所有程序员阅读，无论他使用何种语言）。
! 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.
注意：尽管我们已尽最大努力，只引用那些将继续稳定的、可用的URL，但我们不能保证这一点。如果发现某个引用的链接已经失效，根据你的常识，用你最喜欢的Web搜索引擎进行短语搜索吧。只要可能，我们就将在引用的URL旁边提出搜索建议。
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]
参考文献通常以作者姓名的形式给出。带编号的脚注，用于不合适进入正文的URL，或者用于那些我们怀疑可能将失效的URL；带编号的脚注还用于旁白、论战故事和玩笑[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、World Wide Web，也没有谈到诸如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的The Unix Philosophy [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.
《程序员修炼之道》（The Pragmatic Programmer）[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.
最后，（承认是有意挑起争论，）我们推荐Zen Flesh, Zen Bones [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”是技术上、法律上的商标，隶属于开源组织（Open Group），只应当正式地用于那些已通过开源组织详尽的标准一致性测试认证的操作系统。本书中，我们以一种含义上比较不严谨、但已被程序员广为接受的方式来使用“Unix”，指的是任何这样的操作系统（无论是否正式贴上了Unix标签），它或者是贝尔实验室始祖Unix代码的遗传后裔、或者在很大程度上模仿了始祖Unix代码的遗传后裔。特别指出，在这个定义下，Linux（我们的大部分例子都来自于Linux）就是Unix。
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手册第1小节（用户工具），如果你的系统上有munger的话”。第2小节是C系统调用，第3小节是C库函数调用，第5小节是文件格式和协议，第8小节是系统管理工具。其他小节在Unix系统中各不相同，但在本书中不会被引用到。要显示更多信息，在你Unix外壳提示符下键入man 1 man（对于较老的System V Unix系统，可能要键入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.
本书后面的很多地方，我们会谈到老流派（old school）和新流派（new school）方法。类似于RAP音乐，新流派起始于1990年左右。在这样的时间背景下，新流派与脚本语言的兴起、GUI、开源Unix和Web联系在了一起。老流派指的是1990年以前（尤其是1985年以前）的世界，这是属于昂贵（共享）计算机、专属Unix、外壳脚本以及无处不在的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：
这是两个单独的工程，但通常在一起使用。cdrtools工具包是一组用于光盘刻录的CLI工具；用cdrtools进行Web搜索吧。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邮局协议，从远程邮件服务器上获取邮件。请参阅fetchmail的主页 [http://www.catb.org/~esr/fetchmail]（或者在Web上搜索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 avail-able from the GIMP home page [http://www.gimp.org/] (or search for "GIMP" on the Web).
GIMP:
GIMP（GNU Image Manipulation Program，GNU图像处理程序）是功能齐全的绘图和图像处理程序，能够以完善的方式编辑种类繁多的图形格式。源代码可以从GIMP主页 [http://www.gimp.org/]（或者在Web上搜索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（Multipurpose Internet Mail Extensions，多用途互联网邮件扩展）有很好的支持，并且使用了诸如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和其他XML文档转换为各种输出格式，输出格式包括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以及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是我的测试对象，代表着非技术读者；非程序员也能阅读本书，本书能够达到这样的程度，很大程度上要归功于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）系统架构组提供了有用的反馈。“Unix什么地方做错了”（What Unix Gets Wrong）小节、“深度弹性”（Flexibility in Depth）小节，直接从他们评审中得到启发。Russell J. Nelson为第7章Bernstein链提供了资料。Jay Maynard为第3章MVS案例研究提供了大部分资料。对于“语言”这一章，Les Hatton提供了有益的评注，并促成了第4章关于“最佳模块大小”部分的写作。David A. Wheeler给出了很多敏锐的批评，提供了一些案例研究材料，尤其是在“设计”部分。Russ Cox帮助开发了Plan 9调查问卷。关于C的历史，Dennis Ritchie纠正了我的一些错误。
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.
数百名Unix程序员，这里无法一一列出他们的姓名，在本书2003年1月至6月的公开评审期间，贡献了大量的建议和评注。一如既往地，我发现通过Web进行的公开的同行评审（peer review）过程，充满了激烈的挑战，但回报也是丰厚的。还是同往常那样，书中有任何错误的话，责任在我。
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[3] (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设计模式》的想法。不过我没有，因为我不赞同一些设计模式运动暗含的核心教条，不觉得有必要使用它的正式方法，也不接受它的文化信仰。然而，我使用的方法的确受到了Christopher Alexander工作的影响[3]（尤其是《建筑的永恒之道》、《建筑模式语言》），我从“四人帮”（the Gang of Four）以及从他们学派的其他成员那里获益良多，他们向我表明：在高层次上讨论软件设计时如何使用Alexander的思想，而不会出现模糊的、没有价值的泛泛讨论。对于设计模式导论，有兴趣的读者应该阅读《设计模式：可复用面向对象软件的基础》（Design Patterns: Elements of Reusable Object-Oriented Software）[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.
本书的标题，当然，是参考了Donald Knuth的《计算机程序设计艺术》。尽管和Unix传统没有什么特殊关系，Knuth还是影响了我们大家。
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.
具有远见和想像力的编辑，并没有像期望的那样常见。Mark Taub就是其中之一；他看到了这个已停顿项目的价值，很技巧地推促我完成它。这样的文字编辑——能够非常留意写作风格、具有足够能力改善与他们自己写作风格不同的文字——就更不常见，但是Mary Lou Nohr就是这样的文字编辑。Jerry Votta抓住了我对封面的概念，使得封面看上去比我想象的还要好。我给Prentice-Hall的全体员工打了高分，他们使编辑和生产过程尽可能平稳，他们令人愉快地接纳了我的控制偏执趋向，这可是不仅要控制文字，还要深入到书籍外观设计、插图和市场营销的控制趋向。
Part I. Context
第一部分 背景
Chapter 1. Philosophy 第一章 哲学 Philosophy Matters
Those who do not understand Unix are condemned to reinvent it, poorly.
--
HenrySpencer
Usenet signature, November 1987
哲学有重大关系
谴责那些不懂Unix的人，叫他们拙劣地重新发明它。
--
HenrySpencer
Usenet签名，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.
这是一本关于Unix编程设计的书，但书中我们将多次谈论“文化”、“艺术”和“哲学”。如果你不是程序员，或者你是几乎不触及Unix世界的程序员，这似乎有点奇怪。但是，Unix有一个文化，有与众不同的程序设计艺术，Unix还承载着强大的设计哲学。理解这些传统将有助于你建造更好的软件，即使你现在是为非Unix平台开发软件。
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”.
每一个工程和设计的学科都有其技术文化。在绝大多数工程领域中，作为从业人员所受教育的一部分，学科内未成文的传统与正式的手册、教科书同样重要；随着经验的积累，未成文的传统常常显得更加重要。资深工程师们积累了庞大的未明言的知识体系，这些都将传授给他们的晚辈，传授的方式是（像禅宗说的那样）“教外别传，不立文字”。
（译者注：对菩提达摩开创的禅宗，基本要点归结为四句：
教外别传
A special transmission outside the scriptures;
不立文字
Depending not on words and letters;
直指人心
Pointing directly to the human mind;
明性成佛。
Seeing into one's nature, one becomes a Buddha.
译注结束）
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文化——或者，在21世纪，可以论证它们就是同一种文化。从上世纪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.
Unix诞生于1969年，此后，就一直用于生产性用途。从计算机工业标准意义上看，那是好几个“地质代”以前——比PC、工作站、微处理器甚至比视频显示终端还要古老，与第一块半导体存储器处于同一时期。在今天所有的生产性分时系统中，只有IBM的VM/CMS能够声称存在的时间更长，但Unix机器提供的服务时间是IBM VM/CMS的数万倍；实际上，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的用途范围之广，令人难以置信。Unix可以用作研究工具、技术应用软件的友好主机系统、市场上销售的成品商用软件的平台，同时还是Internet不可或缺的组成部分；除Unix之外，没有哪个操作系统能够在这些应用领域里都能表现得同样杰出。
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.
从Unix的初生时期开始，就有人大胆寓言：Unix将衰亡，或者被其他操作系统赶出舞台。然而，如今化身为Linux、BSD、Solaris、MacOS X以及诸多其他变体，今天的Unix似乎更加强大。
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.[4] Unix has already undergone several such transformations.
--
KenThompson
Robert Metcalf（以太网发明人）说过，如果出现了能够替代以太网的东西，它就将叫做“以太网”，从而以太网永远不会消亡[4]。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 tree-shaped 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 thousandfold 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. 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.
考虑幂指数－时间曲线的计算结果、考虑软件发展的相应步伐，推断的结果之一是：你所知道的东西，每18个月就有50％会过时。Unix不是这个观察现象的例外，反而吻合得很好。没有改变的是根基——语言、系统调用和工具的用法——它们还能使用数年，甚至数十年。其他地方，就不可能预测哪些将是稳定；甚至，整个操作系统都可能不再被使用。在Unix下，短暂知识和持久知识之间的区分相当明显，在你学习某种东西时，基本能事先推断（大概有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息息相依。
[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.
1969到2003的35个年头是段漫长的时间。这个时期，伴随着Unix站点数量的历史增长趋势线，大概有超过五千万人年，干劲十足地投入了到全球Unix开发中。
[2] This particular footnote is dedicated to Terry Pratchett, whose use of footnotes is quite...inspiring.
本条特别脚注献给Terry Pratchett，他对脚注的使用是相当……启发性的。
[3] An 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].
对Alexander工作的赏析，以及指向其书中重要部分在线版本的连接，可以在Some Notes on Christopher Alexander网站找到 [http://www.math.utsa.edu/sphere/salingar/Chris.text.html]。
[4] In 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.
事实上，以太网已经为有着相同名字的不同技术所替代——而且替代了两次。一次是双绞线替代了同轴电缆，第二次是千兆以太网的出现。
