UNIX编程艺术

出版时间：2006-8  出版社：人民邮电出版社  作者：雷蒙德  页数：525  字数：729000  
Tag标签：无  

内容概要

本书主要介绍了UNIX系统领域中的设计和开发哲学、思想文化体系、原则与经验，总结了UNIX发展史上成功的经验和失败的教训、经过时间验证的编码策略以及普遍适用的实用工具。本书由著名的UNIX编程大师、开源运动领袖人物之一Eric S. Raymond倾力多年编写而成，汇集了UNIX之父Ken Thompson等13位UNIX先锋的经典评论。本书内容涉及领域文化、软件开发设计与实现，覆盖面广、内容深邃，完全展现了作者极其深厚的经验积累和领域智慧，是UNIX领域中一本不朽的经典名著。

作者简介

Eric S.Raymond从1982年开始从事UNIX开发。作为开源社区文化的倡导者和呼吁者，他在《大教学与市集》中发表了这场运动的宣言，同时他还编辑了《新黑客词典》一书。

书籍目录

ⅠContext  1 Phoilosphy:Philosophy Matters  2 History:A Tale of Two Cultures  3 Contrasts:Comparing the Unix Philosophy with othersⅡDesign  4 Modularity:Keeping It Clean,Keeping it Simple  5 Textuality:Good Protocols Make Good Practice  6 Transparency:Let Threre Be Light  7 Muliprogramming:Separating Processes to Separate Function  8 Minilanguages:Finding a Notation That Sings  9 Generation:Pushing the Specification Level Upwards  10 Configuration:Staring on the Right Foot   11 Interfaces:User-Interface Design Patterns in the Unix Environment  12 Optimization  13 Complexity:As Simple As Possible,but No SimplerⅢ Implementation  14 Languages:To C or Not To C?  15 Tools:The Tactics of Development  16 Reuse:On Not Reinventing the WheelⅣ Community  17 Portability:Software Portability and Keeping Up Standards  18 Documentation:Explaining Your Code to a Web-Centric World  19 Open Source:Programming in the New Unix Community  20 Futures:Dangers and OpportunitiesA Glossary of AbbreviationsB ReferencesC ContributorsD Rootless Root:The Unix Koans of Master FooColophonIndex

用户评论 (总计35条)

•   令狐冲学剑，先学剑招，再学剑意，这本书就是这个意思。书中并没有太多关于技术理论的探讨，如果需要学习Unix编程，可以看Unix高级编程之类的书，或者LInux编程白皮书当入门也可以，这本书需要对Unix的设计思路有一定了解才可以，比如，到底什么叫“简单”，什么才是最适合的接口，程序应该做什么，不应该做什么。如果你只会用Windows，理解起来可能有些困难，因为有些思维上的东西与Windows是格格不入的。不过如果你了解Unix或者Linux，那么可以看一看这本书，不仅是技术，更多的是习惯。比如，看了这本书，一个很没有头绪的项目就让我想出了方案。项目中有一堆根本不粘边的功能模块，而在细节的地方却需要通信。没有人能预测这些“细节”是否会变成下一期的核心功能。看了这本书，我才明白，应该把所有功能做成小软件，在一定程序上，这些小软件还可以独立运行，但可以通过统一的接口粘合成整套系统。现在这个系统正在开发中，状态不错。早就读过这本书，是中文版的，看到这本书就快买下来了，哪怕是纪念也好，最起码也应该读一读英文原版。值得不断地去读，这本书，加上算法导论，还有计算机程序设计的艺术，都是值得一生珍藏的好书。读这本书，需要了解Unix，Linux的哲学思维，但不需要你一定是高级程序员。这本书不仅值得程序员去读，也适合中国做IT项目的客户，项目经理，产品经理去读，同时也适合大学生去读。比如，有些人只知道用Word打字，一个通知十来个字也用Word，发个邮件也用附件，这本书同时也会教会你，文本文件才是最节省资源，并且是全“宇宙“统一的通信接口。真的是一本好书。看起来，感动加过瘾，同时还会有点伤感，为我周围的人对Unix，KISS的不理解而伤感。好书不用我夸，大家自然知道。
•   大牛经典！！
•   居然都没中文版的了，不过内容确实很充实，组织得也很好。英文写得可能比较地道，毕竟很多都是经验之谈而不只是具体技术介绍，读起来还是有些吃力。
•   很好甚强巨
•   对Linux历史以及文化都很有涉及开源的鼓吹者在此基础上阐述了Unix编程中的原则和思想
•   外表上有撕掉胶布的胶的残留物，黄黄的。书侧面很脏，比我用过的二手书都脏，很失望。我原本不想在书评上写这些无关的话，但是我觉得再好的书，如果买到就是个破烂的，怎么也不能高兴起来，所以我希望你看到了这些能对你有所参考。我不能说所有的书都脏，但是我的书确实很不好。
•   　　之前读过《Linux/Unix设计思想》一书，加上这些年使用Linux的经验，对Unix的一些思想有所了解。读这本书就是一个老牌黑客给你讲各种经验和故事，穿插着上古时期的各种大神尊者的趣事。
  　　
  　　1.6章的目录总结了Unix的设计哲学：
  　　
  　　1.6 Unix哲学基础 11
  　　1.6.1 模块原则：使用简洁的接口拼合简单的部件 14
  　　1.6.2 清晰原则: 清晰胜于机巧 14
  　　1.6.3 组合原则：设计时考虑拼接组合 15
  　　1.6.4 分离原则: 策略同机制分离，接口同引擎分离。 16
  　　1.6.5 简洁原则：设计要简洁，复杂度能低则低 17
  　　
  　　1.6.6 吝啬原则: 除非确无它法，不要编写庞大的程序。 18
  　　1.6.7 透明性原则：设计要可见，以便审查和调试 18
  　　1.6.8 健壮原则: 健壮源于透明与简洁。 18
  　　1.6.9 表示原则: 把知识叠入数据以求逻辑质朴而健壮 19
  　　1.6.10 通俗原则：接口设计避免标新立异 20
  　　1.6.11 缄默原则：如果一个程序没什么好说的，就保持沉默 20
  　　1.6.12 补救原则: 出现异常时，马上退出并给出足量错误信息 21
  　　1.6.13 经济原则: 宁花机器一分，不花程序员一秒 22
  　　1.6.14 生成原则: 避免手工hack，尽量编写程序去生成程序 22
  　　1.6.15 优化原则: 雕琢前先得有原型，跑之前先学会走 23
  　　1.6.16 多样原则:决不相信所谓“不二法门”的断言。 24
  　　1.6.17 扩展原则: 设计着眼未来，未来总比预想快。 24
  　　
  　　总结成一个词就是： KISS.
•   　　最近这段时间比较忙，利用业余时间看完了这本书。虽然书中讲到的很多例子都是上古文物，我没有用过，不过原理都是相通的，对我的启发很大。比如无所不在的KISS原则，实践中慢慢体会到的SPOT原则，无不产生共鸣。下面是这些原则的一些笔记和个人理解。
  　　
  　　1. 模块原则
  　　
  　　为什么要模块化？计算机编程的本质就是控制复杂度。而模块化可以降低整体复杂度，即使出现问题也只是局限于局部，方便维护。
  　　
  　　紧凑性和正交性是模块化的两个重要特性。对于现代项目来说，跨度一般都很大，完全达到紧凑性是非常困难的，只能尽量采用。
  　　
  　　正交性是指程序中每个动作有且只有一个方法，正交性的程序不但会减少程序中的副作用，而且从另一个方面达到紧凑性。SPOT（single point of truth）是指任何知识点在系统内应当只有一个唯一明确权威的表述。不要重复自身。重复会导致前后矛盾。重构的原则性目标就是提高正交性。
  　　
  　　2. 清晰原则
  　　
  　　所谓大巧不工，重剑无锋。程序的清晰性比奇技淫巧更重要。选择算法和实现时应考虑可扩展性和可维护性，复杂的bug容易产生bug，难以阅读维护。同时在项目中养成注释代码的良好习惯。
  　　
  　　3. 分离原则：
  　　
  　　策略同机制分离，接口同引擎分离。策略是易变的，灵活的；机制是稳定的。策略与机制混在一起会有两个负面作用：1.使策略死板，难以适应用户需求变化。2.任何策略的改变都极有可能动摇机制。而分离开来可以在探索新策略时不去改变已有机制。
  　　
  　　实现策略与机制分离的常用方法就是用脚本语言驱动的c语言实现机制，打包成库。整个应用程序的控制流程则有脚本语言来控制，这就是策略。比如我们公司的产品就是策略机制分离的典型应用。底层引擎由c和c++实现，lua做接口，上层流程用lua脚本实现，用户可以在一定范围内自己设计流程。
  　　
  　　不过上层策略和下层机制分离并没有那么容易，不管是从上到下还是从下到上的设计方向都有弊端。当上层的策略与下层的机制产生冲突时就可能需要中间胶合层来匹配。胶合层应该尽可能薄，薄胶合层是分离原则的升华。C语言是薄胶合层的典型范例，而面向对象语言则属于厚胶合层，特别是继承层数太多时，会严重增加复杂度。
  　　
  　　4. 简洁原则
  　　
  　　出现越复杂，产生bug的概率就越高，排错也越困难。以简洁为美，拒绝花哨臃肿的程序。Keep it simple, stupid!
  　　
  　　5. 透明性原则
  　　
  　　透明性是针对程序的行为而言的，如果程序行为在一定程度上可以预测，那么程序就是透明的。可显性指的是程序的功能很清楚，容易明白做了什么，怎么做的。比如Linux内核具有透明性，我们知道具有什么行为，但是不具有可显性，因为源码太复杂难懂了。
  　　
  　　6. 健壮原则
  　　
  　　健壮性指程序不仅在正常情况下运行良好，而且在超出设计者设想的意外条件下也能运行良好。尽量让程序的内部逻辑更易于理解，使其透明化和简洁化，最好避免程序出现过多特例和边界条件。
  　　
  　　7. 表示原则
  　　
  　　数据比代码逻辑更清楚明了，设计时主动将代码的复杂度转移到数据中去，选择偏于维护和操作的数据。数据驱动编程是unix编程的重要组成部分。
  　　
  　　8. 通俗原则
  　　
  　　接口设计避免标新立异。最易用的程序就是用户需要学习东西最少的程序，一定避免表面相似但内部却不同的情况，比如重载函数内部行为变化太大。
  　　
  　　9. 缄默原则
  　　
  　　设计良好的程序将用户的注意力视为有限的宝贵资源。信息内容应该符合最大惊奇原则，只对确实是异常的情况加以说明。如果调试需要，可以添加多级开关，发布时启用最高级别开关。
  　　
  　　10. 补救原则
  　　
  　　出现异常时，马上退出并给出足量错误信息。软件在发生错误时如果没有及时发现，将会埋下严重的隐患。软件应该能够从容应付各种错误，如果做不到，就应该明确终止。有些时候程序不应该去容错，比如输入为空时最好直接退出并保留恢复机制和错误信息，处理输入后再重启，而不是检查输入是否为空，当数据出现问题却恰好不为空时将会产生非常隐晦的错误。
  　　
  　　11. 优化原则
  　　
  　　过早优化是万恶之源。先制作原型，再精雕细琢，优化之前先确保能用，不要为蝇头小利投入过量时间。
  　　
  　　同步于
  　　http://www.cnblogs.com/coderkian/p/3581468.html
  　　
•   　　这本书，断断续续，花了两年的时间才基本看完一遍，因为时代过于久远，其实很多内容并不能产生共鸣和体会，但是单单那些能体会到的，就有足够的理由买来看这本书了。很多有趣的Unix的历史、很多软件开发的指导原则、对文本格式的偏执、数据驱动、进程间通信、性能优化原则、可移植性确保了生命力等。 对于我个人来讲有一点是非常印象深刻的：代码重用的关键在于透明性，而开源是实现透明性的有效方式。
•   　　 别人的评价都很高，我看的中文版，感觉翻译的有的地方看的不顺畅！自己也是程序员，感觉好多词看着拗口，但是大体意思是看了，作者洋洋洒洒写了许多哲理及软件及系统的设计原则，最震撼我的是里面说c++ 及别的语言有许多的不合理地方，我们当时学习c++等等别的都是认为就应该是这样，作者功力深厚批判的很多东西！
•   　　目前读到了第13章，中文版的。
  　　如果想了解Unix的哲学，并且从多个视角去了解Unix，无疑，TAUP是一个很好的起点。
  　　不管是Unix的设计原则，还是Unix的诞生历史，ESR都信手拈来。
  　　每个章节的组织都是松耦合的，这也给了读者极大的阅读自由！
  　　
•   　　内容涵盖从philosophy 到 practical issues。
  　　其实K.I.S.S. 的概念很简单，容易理解，但是就知道K.I.S.S. 的概念是远不够的，理解并运用K.I.S.S. 才是我们的最终目标。本书包含的很多Case study 非常值得一看，里面包含了多年实践的经验，已经对未来软件设计的指导, very nice.
•   　　如果有人完全了解了某种事物，他就有一种不吐不快的冲动，想把了解的一切细节告诉所有人，这就是我读完这本书的感受。
  　　
  　　阅读这本书需要一个前提，就是你认可“Unix哲学”是正确命题，也就是说这本书是写给Unix爱好者的——是写给特定人群的书。
•   　　这本书已经不是一本技术书，已经深深阐述到哲学层面了，很多次抑制不住想读它的冲动，每次去读，都失望而归，因为其中语言容易理解，意境却很难参透。随着工作经验的增长，偶尔有人推荐，还是回去读它，终于逐渐读懂了一点点。
•   　　毕竟Linux的修养有限，估计以后再看的时候，会更好的体会这本书想传达的内容。
  　　毕竟Linux的修养有限，估计以后再看的时候，会更好的体会这本书想传达的内容。
  　　毕竟Linux的修养有限，估计以后再看的时候，会更好的体会这本书想传达的内容。
•   　　如果早三年就去读，我的人生必将不同。如果早五年来读，大概我还读不懂。
  　　
  　　写程序做项目，许多事情没有经历过，是很难体会的。（刚写了一大段攻击C++的文字，怕引起圣战，就删了。此处省略300字。）
  　　
  　　好吧，总之，不论经验丰富还是初出茅庐，都建议读一读。也建议过一两年再捡起来重读一次，将有不同的感悟。
  　　
•   　　从作者写书到我读这本书已经事隔十年。 对于一个使用linux有2年的人（其实我一直不认为经验年限和对一件东西的了解程度有线性关系），我阅读完之后的感受是：有些观念很深入我心，有一些却不了解，或者根本提不起兴趣看。
  　　还是说说那些深入我心的感悟。
  　　1，机制和策略的分离，每个程序只做一件事，并且把它做好。这个观点作者多次提到。可以从两个经典实例来说明：（1）linux/unix内核API设计：与windows相比，linux的系统调用确实设计的简洁而且每件事只有对应的API，每个API只对应与一件事。那么其实这些系统调用就提供给我们机制，剩下要完成什么功能（策略）就很自由的取决与我们的需求。（2）x window：这个更是可以解释机制和策略分离，在x window底层提供各种机制，具体的GUI着由高层程序员调用API（机制）来完成策略。GNOME，KDE就是具体的策略。
  　　2，作者对CLI（commend line interface）软件的配置的解释也是让我对它有更抽象，高层次的理解。 一个unix软件的配置有几个方面：系统配置脚本，用户个人配置脚本（dot 文件），命令行参数（分为 - 和 --）。
  　　3，作者对于微型语言和脚本语言的理解。其实作者多次交叉提到，涉及的方面也挺多。首先，语言由功能的不同可以分为：描述性语言（html，xml等），具体的功能语言（C，C++，java，python等）功能性语言本质上都可以用来完成任务，由于其语言特性，它们擅长不同领域。其中不得不说的是：关于GUI程序的脚本接口问题。一个GUI程序对于高级用户，程序员来说，最可能的使用瓶颈就是缺少脚本接口了。这样复杂的任务就必须依靠一系列的点击来完成，而且很容易点错。合理的设计就应该有脚本语言或者说微型语言可以控制它，这方面的经典就是SQL，作为控制数据库的微型语言，无疑比GUI点击要好，这点估计初学者也会这样认为。
  　　好了，其实挺多的有用的观点的，作者能以这么高观点来看问题，而且能把它写下来成书确实不容易。
•   　　
  　　http://herpolhode.com/rob/ugly.pdf
  　　
  　　The Good, the Bad, and the Ugly: The Unix! Legacy
  　　
  　　high-level programming language
  　　hierarchical file system
  　　uniform, unformatted files (text)
  　　separable shell
  　　distinct tools
  　　pipes
  　　regular expressions
  　　portability
  　　security
  　　
  　　虽然很短但是感觉超过了本书。
•   　　以前学c基础的时候就看了一遍taoup，里面的例子都没接触过，依然感觉收获很多，记住了KISS，了解了unix哲学，对一些东西有了个模糊的概念，始终深刻地影响着的我的编程时的一些想法。
  　　
  　　最近刚学完unix系统编程，昨晚再次翻看taoup，有些东西能真的感觉到了，感慨万千，打算细看apue的期间再读一遍taoup，太好的书。
  　　
  　　好书要趁早看，好书会看多遍，学习那一阶段错过后再看就相逢恨晚了
•   　　原著成书于2003年，而且作者说写了5年。从2003到现在2011已经又8年了，许多事情又变化了。。。
  　　这本书在学校就读过，但当时也就是读过一遍，略微记住几个名词而已，比如KISS和文本化，现在回想下，这两个概念对自己影响确实蛮深的，当初没有白读。最初阅读时，好多软件都没有接触过，也谈不上写过多少代码，书中好多东西也就那么过眼了一遍而已，在把书还给图书馆时就嘱咐自己将来一定要再读。
  　　现在不一样了，离开学校从事软件开发实践也两年多了，很多工具都用过了，也有了新的认识，也仍有不少工具尚未接触。正好上半年部门组织读书，就推荐购买了这本2011年版的，工作闲暇加上昨天下雨不愿出门又看了一遍。
  　　译者说作者是美国愤青，应该说是Unix愤青、Unix死忠，很多地方偏激了点或者教条了点，真应该到unix以外的世界走走。当然作者毕竟大师级明白人，20.3节中把Unix的问题都数落了一遍。毕竟unix基本已死，就是承继其衣钵的Linux占有率也就1个百分点，另一个亲戚MaxOS X和iOS日益兴隆8个点了。
  　　有人批评作者老高抬自己的fetchmail，哈哈，这个嘛，罗马城不是一个人建成的，你不能期盼作者什么都懂。我在看书也老联想自己开发的那几个小工具，给别人举例也爱提它们。毕竟作者对fetchmail知根知底啊，如果作者举个不太熟悉的例子万一说错了岂不招来更大的争议。
  　　1.6节那17个原则全部值得牢记于心，如若真的记不住全部，那就记住KISS这个单词吧，若不满足一个词那就再来句David Gelernter的话——美是抵御复杂的终极武器。什么是美？清晰、简单、真相、省力，这就是Unix哲学的全部。
  　　
  　　说说03年到现在变化的东西吧：
  　　1、OOXML继ODF后成为了最新的国际文档标准，这是XML格式和“文本+压缩”解决方案的重大成果。除了XML，更美的json也是有标准的。
  　　2、版本管理工具方面：svn已成最广泛使用的准工业标准工具；Linus开发了Git取代了BitKeeper用来管理linux源代码，而且以Git为老大Mercurial和bazaar等垫后的DVS已大有替代svn之势。
  　　3、语言方面。javascript日益光鲜，Python更加强大，Ruby的吸引力也还算不错，但还是作者345页评论的“似乎很有前途”。另外Lua作为可嵌入语言崛起了，Object C背靠MacOS X和iOS攻城掠地。google都推出了Go语言，不能怪作者独守unix一隅，只能说这个世界变化太快。
  　　再批评下作者吧：
  　　4、编辑器和IDE方面。你就用下IDE会死啊？Eclipse、NetBeans和Visual Studio等。大工程还得靠IDE来提高生产力。
  　　5、产品要大卖，还得靠大方漂亮的GUI。
  　　
  　　
  　　
  　　----------补充一些写作、翻译和印刷遗憾-----------
  　　1、中文目录1.6.2和1.6.4的章节标题中冒号是半角的吧，而其他15个标题都是全角的。
  　　2、420也最后一行那个是C1I还是ClI，下次记得印刷成CLI。
  　　3、308页13.2.4节最后一句话，维->难。
  　　4、470也说C语言是弱类型语言，这个翻译错误太大了。
•   　　这是一本关于unix开发哲学的书籍。也是一本历史书籍。你既可以从中了解unix/linux一路走来的历史，也可以了解到她背后的哲学，以及那些来龙去脉。
  　　
  　　在作者看来，基于同行评审的代码检查与查看是unix兴起的基本要素，尤其在unix与TCP/IP融合后，unix的文化也发生了变化。直到开源运动的兴起，新unix，即linux，的出现，标示这场运动的一大成就并意味着一个巨大的里程碑。任何闭源的unix都走向失败，而开源的则走向成功。
  　　
  　　对于个os的历史和基因属性也给的比较明确，最典型的如Mac OS/X，当代OSX有着高度的BSD UNIX混血，但也有Mac OS的特性。 NT倒是自成一家，从其他体系上发展而来。但现在都往POSIX上面靠了。
  　　
  　　脚本和code故事也是一种纠结，基于文本比基于二进制要好，进程协作比一个大块头要好，Break是其中的关键，微型语言如reg、js是重要的，少吃多干还是多次多干并没有定论。
  　　
  　　工具是重要的，文档则在全面HTML化和标记化，许可证MIT和BSD是善良的，GPL那是很凶的，命名规范是要注意的，_和数字是不能随便瞎用的。foobar-1.1.2.i386.bin.tar.gz要比foo_bar1.1.2.i386.tar.gz好。
  　　
  　　configure / make / make install是一个咒语。configure的目的是生成make文件，当然是根据机器的情况生成。
  　　
  　　UNIX的GUI是不行的,CLI是很行的，结构更是很好的，所以再优秀的os也有需求和UNIX融合的。
  　　
  　　更重要的，在产品背后的是开发产品的人。
•   　　这是一本圣经一样的宗教读物。
  　　你可以藉由它来了解unix/linux这个宗教群体的思维模式，至于是否要遵从它的教义进行实践，请慎之又慎。
  　　==============================
  　　Linus Torvalds不光是对C++有意见，他对“抽象”俩字的意见就大得很。
  　　不过这也容易理解，Linux文化的特征就是hacker传统，他们分不清也不想分清programmer与user的区别，所以不论你是职业程序员还是家庭主妇，要想用linux，你就只能把自己当作一个hacker。
  　　
  　　轻视抽象的结果就是：
  　　当一个家庭主妇坐到一台Linux机器面前的时候，她看到的是和天才程序员Linus Torvalds看到的一样赤裸裸的机器……
  　　
  　　The Art of UNIX Programming中，Eric S. Raymond再次有意无意地显示了Torvalds们对于抽象的态度（5.1 The Importance of Being Textual）。
  　　
  　　保持配置文件being textual的理由竟然是为了能够用普通的文本编辑器来编辑它们。
•   　　刚开始翻的时候觉得,全是码字代码没几行,觉得很水,看过之后才发现绝对是一本好书.对UNIX程序设计又有了新的认识.
•   　　我承认有些书看过之后确实让人脱胎换骨，只要你愿意去转变思维方式！我最早认识这本《Unix编程艺术》是在大学阶段，那时候以为就是本unix的手册呢！但是不知道为什么在一些经典书的尾页上总是推荐这本书，直到最近才鼓起勇气去查查内容，好家伙，这种书就是我要找的！可怜的是我现在才发现，还好我还有几十年的活头！以前用Cygwin的时候总觉得别扭，现在找到病根儿了——没看这本（哲学）书！对了！我没说错，这是本哲学书，不局限任何一种语言！这本书像《The Pragmatic Programmer》一样震撼这我，好久没看到这么偏执的书了！真是一种享受（当然不偏执的人看了以后会觉得作者就是个疯子）！建议每个程序员都买一本，然后做好重生的准备......
•   　　在OO和OP决策的浪潮中, 我们该如何取舍? 为什么OP可以有如此优越的特点, 可以维系Unix发展这么多年? 毫无疑问Unix是一个完美的软件项目, 不是其效率有多高, 而是其令人叹服的生命周期, 围绕Unix开发的的那些经典的软件, 他们存在了一些共同的特点, 这些在很多的面向OO的设计中, 也不经意中提及， 但是， 你可以在这本书中，找到一个最深入的答案。 总有一些让你为之喝彩的经典总结. 我的评价只有两个字: 力荐！
•   　　这本书买的比较晚，却是赶在其他书之前最先读完。前前后后估计读了三个月有余，当然因为中途有好看的小说插队，以至于耽搁了不少。
  　　
  　　这个标题很容易让人以为和那部旷世巨作一样，还好通过评论，已经知道是一种思想的阐述。所以刚才，当我把书放回书架的时候，犹豫了一下，还是放在《代码大全》的旁边，毕竟总的来说，他们是同一类型的，只是《代码大全》关注的是细节，而《Unix编程艺术》是一种大的宏观的实践，至于是否最佳实践，当然是仁者见仁的问题了。
  　　
  　　感受了KISS原则，像追星一样这段时间把msn的签名都改成Keep !t S!mple and Stupid 。毕竟这个原则深得我心，因为我也是一个程序员的缘故吧。
  　　
  　　工作需要，有时候在linux或者unix上操作，那些小巧实用的工具让工作轻松不已。但是开发机毕竟还是windows的机器，时常会想去寻找unix工具的替代版本，比如说tail，那时候很是感慨的和一个做.net的同学宣扬这些工具的好处，宣扬linux系统多么的善解人意。
  　　
  　　虽然自己不是unix程序员，但是unix的好多理念其实早就脱离unix本身，这一点也是感受颇深的，尤其在opensource领域。所以当读到后期，真的是有种废寝忘食的感觉了。凌晨一点才依依不舍的放下书本，熄灯睡觉，早上8点还坐在沙发上捧着该书。
  　　
  　　从上不难看出，我对本书的推崇，不过好玩的是，当我读完最后一部分《无根之根》的时候，合上书本，心里却在想，是不是要把它当作二手书卖掉？读过了，领会了，其实一切都那么简单，在合适的时候去贯彻就行了，至少对我而言不会像其他书一样去反复翻阅——书架上待读的书实在太多了
•   　　昨晚看了一下关于yacc和lex的部分，里面把预处理叫做前处理，难道是用某个程序翻译的？这部分我几乎是“读”下来的，但还是不懂，于是看了英文版的
•   　　3.1.3 Cooperating Processes
  　　 it would not have been trivial without the fundamental unifying notion of the process as an autonomous unit of computation, with process control being programmable.
  　　
  　　这句被翻译成了：……进程是自主运算单元的统一性记号……
  　　
  　　你能明白这里的“统一性记号”是什么意思吗？notion只有“记号”的意思？这里使用的是“概念”的含义，即“……将进程视为一种自治性运算单元的概念……”
  　　
  　　
•   　　我从图书馆无意间找到的书,这几天大概的看了看.. 感觉好多都看不懂.. 不过文字真的很是有味道,不枯燥~~
•   翻译水平不敢恭维啊，应该买另一个版本的unix编程艺术
•   ppt最后一页内容：
  1.What is the best thine about UNIX?
  A: The community.
  2.What is the worst thing about UNIX?
  A: That there are so many communities.
  耐人寻味之。。。
•   这本书是taoup吧..
•   我觉得还是不要认为看这一节能把YACC&LEX搞明白，毕竟一小节想把这2个工具搞明白似乎有点难。
  可以参考其他书籍。
  等会用YACC&LEX回头再看这一节是否会好一点。
•   我在看manual。原本也不是想通过它了解bison的，只不过看到上面在说这个，就先看了一下。
•   Good point, I will not buy this translated version.