不经意看到袁德俊兄将初译稿发在blog上，以开源的方式征求意见（http://blog.csdn.net/yuandj/archive/2004/07/08/36969.aspx），觉得很不错。就想把我的初译稿也拿出来晒晒。虽说一个文章的译文放到两处不太好，可是由于我也参加比赛，那些内容全译了，跟袁兄的出入很大，全放过去的话估计看起来受不了了。
希望大家也能多给我一些批评，一起进步嘛！
相关链接：
CSDN的TAOUP征译启事：http://www.csdn.net/news/newstopic/16/16101.shtml
TAOUP原文下载地址：ftp://download.csdn.net/taoup.rar
ChangeLog：
时间
改动
贡献人
备注
2004-07-16
贴到blog上
西门吹牛（我）
无
2004-07-16
改了第一句话
Solstice更正之
在袁兄那里看到
2004-07-16
原来漏翻了一句，加上
我
看人家的翻译才发现漏了，惭愧
下面就是我的初译稿
译文对照表：
词/句
译文
备注
expertise
专家技能
若译为“专长”则有些地方不通顺
technicalia
技术细节
猜测，未知单词
bloat
代码膨胀
port
移植
context
背景
community
团队
transaction
交流
agreement
和谐
本应是“协议、一致”
pretend omniscience
装扮成上帝
这里的意思是说，上帝是“三位一体”的，作者用“我们”看起来好像他也是“三位一体”的，呵呵
folklore
民间传说
用在这里好像不大妥当
asides
道听途说
这里不知是用作名词还是asides than？？
vital
起决定性作用
mysteries of X
Xwindow秘笈
这里的X不知是不是指XWindow
tap
利用
make good use of
case study
案例研究
major general-market or vertical application
主营市场或垂直应用
说实话不知道这两个名词什么意思
aphoristic
格言
paced
定位
war stories
《星战》故事
好像老美挺欣赏这个科幻的说
mined this territory
在该领域有所斩获
disquisition
著作
原意“专题论文”，见disquisition
ground
话题，论题
位于ground
Zen Flesh, Zen Bones
《禅之精髓》
therapeutic form of mental discipline
智力训练的治疗方式
位于therapeutic form of mental discipline
facilities
功能
well-established
源远流长
renders
表现
位于renders
inspire
促成
位于inspired
motivate
促成
位于motivate
toss around
谈到，谈及
implicit knowledge
潜移默化的知识
原意应为“隐含的知识”，我的翻译或许更妥帖。见implicit knowledge
ephemeral
短暂的
see
见识
用在这里可能比较恰当，见seen
mind-bogglingly
使大吃一惊的
原意没查到，不过boggle含有“吓倒”的意思
shone simultaneously
与之媲美
直译的话是“同样地耀眼”
Preface
前言
Unix is not so much an operating system as an oral history.
Unix并非一个如传说中一样的操作系统。
（参照袁兄那边的意见，改为：
与其说 Unix 是一个操作系统，不如称之为一部口头历史）
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开发的方方面面（尽管这些专家们本人都没意识到他们了解这些内容）。因而，与其它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所提供的，帮助你解决问题的软件工具。第四部分（团队）则阐述了人与人之间的交流与和谐，正是这种交流与和谐，使得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-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.
除了所有这些技术细节之外，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文化的方式就是通过渗透，从其他人和传说中学习。本书并不是人对人的文化传承的替代品，但它能够让你利用其他人的经验，从而加快学习的进程。
注①：1969到2003这35年是段不短的时间。根据那段时间的Unix站点数的历史趋势曲线来看，全球大概有5千万人年投入到了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环境给予比通常的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.
因而，尽管（在本书中）你会常常受邀阅读一些代码和具体的文件，相对而言，他们很少被包含在书中。相反，我们为您指出这些例子在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 aWeb
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系统上的考查而言，软件案例学习将会是已经安装好的并且马上能用的。书中的指示鼓励你去浏览和实验。这些指示的介绍都有定位标识（译者注：可以参见List of Examples），因而离开去浏览一会儿并不会打断需要连续进行的展示。
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链接，或者是那些我们怀疑可能会被删掉的内容；或者是些道听途说，《星球大战》的故事，笑话之类的②。
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.
为了让这本书更易于让技术性不强的读者接受，我们邀请了一些非程序员来阅读，并且指出那些对展示的流程既是（阅读）障碍又是必不可少的术语。我们也用脚注来给出一些基本术语的定义，这些定义对有经验的程序员而言通常都是不需要的。
注②：这个脚注是献给Terry Pratchett的，他对脚注的使用是……呃，令人鼓舞的:^)
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开发者的论文和著作在这个领域曾有所斩获。
Kerninghan和Pike的《Unix编程环境》[Kerninghan-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的《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 higherlevel
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.
《编程的实践》[Kerninghan-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"从技术上和法律上来说是Open Group的注册商标，而且仅允许正式地用于那些经过了Open Group的细化标准一致性测试认证的操作系统。本书中，我们使用当前在程序员中广泛认同的"Unix"的更加宽泛的含义，来指代所有的直接继承自贝尔实验室的原始Unix代码的，或是以非常类似它的后代的代码的方式写出的操作系统（不管它是不是正式的以Unix为商标的）。特别地，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节（用户工具）中找到相应文档，如果它在你的系统中存在的话"。第2节是C系统调用，第3节是C库调用，第5节是文件格式和协议，第8节是系统管理工具。其它的章节随Unix系统的不同而不同，不过它们在本书中都没有引用到。要了解更多，请在你的Unix shell（译者注：我不想把shell译为"外壳"，还是保留吧）提示下键入man l man（老的System V Unix可能需要man -s l 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 memoryconstrained machines have wrought some significant changes on the Unix programming style.
在本书后面不同的位置上我们都提到了"老学校"和"新学校"方法。"新学校"和rap music一样开始于上世纪90年代。在这个背景下，它与脚本语言、图形用户界面、开源的Unix和网络的兴起联系在一起。"老学校"指代的是90年代之前的（特别是1985年之前的）世界，那个时代充斥着昂贵的（共享的）计算机，私有的Unix，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包是一组用于写CD-ROM的CLI工具；到网上搜一下“cdrtools”。xcdroast应用程序是cdrtools的一个图形界面；参见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程序通过POP3或IMAP邮件协议从远程的mail服务器接收邮件。参见fetchmail的主页[http://www.catb.org/~esr/fetchmail]（或在网上搜索“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（GNU图像处理程序）是一个全功能的绘、画及图像处理的程序，能够以精细的方式编辑多种格式的图像。GIMP的主页有相关的源程序[http://www.gimp.org/]（或在网上搜索“GIMP”）
mutt The mutt mail user agent is the current best-of-breed among textbased 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 邮件用户助理是现有的基于文本的Unix电子邮件助理同类产品中最出色的，它拥有对MIME（多用途Internet邮件扩展）极好的支持和对隐私辅助程序如PGP（Pretty Good Privacy，这个不用翻了吧？）和GPG（GNU隐私卫士）的支持。[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指令能够将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是代表非技术类读者作为本书的试阅人的；关于本书能够为非程序员人群所接受的程度，很大程度上都得益于她。
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为我指明了"最少惊奇"原则的出处。UIUC系统架构组对前面几章给出了很有用的反馈。"Unix在哪里犯了错"和"深入探究可伸缩性"两节都是直接由他们的审阅所激起的。Russell J. Nelson 为第7章中有关伯恩斯坦链的内容提供了素材。Jay Maynard 则为第3章中有关MVS案例研究的内容提供了素材。Les Hatton 为"语言"一章提供了很多有益的注解，并且促成了第4章"优化的模块大小"中的部分内容。David A. Wheeler 提出了很多敏锐的批评以及一些案例研究的素材，尤其是关于"设计"那一部分的。Russ Cox帮助展开了"计划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.
有成百上千的Unix程序员，由于人数过多而无法在此一一列出，他们在2003年1月到7月的公开审阅期间提出了很多的建议和评论。一如既往地，我发现通过网上的公开平等的审阅既充满了激烈的挑战意味又有着热情的回报。同样一如既往的是，修改最终的产物中的错误还是我自己的责任。
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 work3 (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的著作的影响③ （特别是《建筑的永恒之道》和《模式语言》），而且我对"四人帮"和他们那派的其他成员充满了感激之情，因为他们向我展示了如何在软件设计领域利用Alexander的洞察力来进行更高层次上的交流，而不是仅仅发出一些含糊不清、毫无意义的嘟囔。感兴趣的读者应该看看《设计模式：可复用面向对象软件的基础》[GangOfFour]，以便对设计模式有一个基本的了解。（译者注：《设计模式》一书现在已成为设计模式领域中的圣经，而著者四人通常被亲昵的称为Gang Of Four，或是缩写为GOF，这里我们把他们称作"四人帮"没有一点诋毁的意思。相应的，这本书通常也被称为GOF设计模式）
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的《计算机程序设计艺术》一书的标题而作。尽管Knuth与Unix传统并没有什么具体的联系，但他影响了我们所有人。（译者注：Knuth在计算机领域是一位宗师级人物，其著作The Art of Computer Programming也被奉为程序设计经典书籍（教材）。同时他的写作风格也影响了一大批的技术作家）
注③：对Alexander著作的正确评价，以及一些重要内容的on-line版本的链接，都可在“Some Notes on Christopher Alexander”网站 [http://www.math.utsa.edu/sphere/salingar/Chris.text.html]找到。
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的全体工作人员都给我留下了很好的印象，因为他们努力降低了编辑和出版流程（给我）带来的困扰，并且很乐意的接受了我在文字中表现出的，甚至深入到了书的视觉设计、艺术、市场等等细节中的“控制癖”倾向。
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的系统上进行开发。
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".
工程学和设计的每个分支都拥有技术性的文化。在绝大多数的工程学中，该领域中未见诸文字的传统都是在其中工作的从业者教育的一部分，与官方手册和教材同样重要（而且，随着经验的增长，可能会更重要）。工程师前辈们发展出了大量的潜移默化的知识，这些知识是通过一种（禅宗教徒所提倡的）"在文字之外的特殊的交流机制"来传播给他们的后辈们的。
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）更久，而安装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所支持的广泛的应用范围足以使你大吃一惊。作为研究用的样机，作为定制的技术应用的友好的宿主环境，作为商业标准的业务软件的平台，并作为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.
那些自信满满的预言要么说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.④ Unix has already undergone several such transformations.
Robert Metcalf（以太网之父）说，如果有什么东西涌现出来代替掉以太网的话，那玩意儿就会被叫做“以太网”，所以以太网永远不会消亡④。Unix早已经经历过若干次这样的转化了。
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还引入了如今被广泛采纳的带有目录节点的树形文件名字空间，以及用于连接应用程序的管道(pipeline）功能。（开始漏翻了这句）
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仍然高高在上地注视着这一切，仍然在生产，仍然在支付帐单，而且仍然拥有这个星球上最好最聪明的软件专家的忠诚。
Once when coax was replaced with twisted pair, and a second time when gigabit Ethernet came in. 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.
一次是双绞线取代了同轴电缆，又一次是千兆以太网的降临。在计算领域成级数方式增长的能量vs时间曲线，以及相应的软件开发的进步，带来的影响之一就是一个人的知识每18个月就被淘汰掉50％。Unix也无法回避这种现象，而是做了很好的工作来容纳它。有一些不会动摇的基础构成了（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的共生中得到了持续的、成功的传播。
注④：实际上，以太网已经被具有同样名字的不同技术所替代了--而且有两次之多！
