本网站不提供下载链接，喜欢看书的朋友请关注公众号：【lennylee的碎碎念】(lennyleede)，首页回复：授人以渔，自动获取搜索资源的方法。
内容简介:
《UNIX编程艺术》主要介绍了 Unix 系统领域中的设计和开发哲学、思想文化体系、原则与经验，由公认的 Unix 编程大师、开源运动领袖人物之一 Eric S. Raymond 倾力多年写作而成。包括 Unix 设计者在内的多位领域专家也为本书贡献了宝贵的内容。
书中内容涉及社群文化、软件开发设计与实现，覆盖面广、内容深邃，完全展现了作者极其深厚的经验积累和领域智慧。
作者简介:
Eric S. Raymond 从1982年开始就是UNIX开发者。作为开源社区文化的倡导和呼吁者，他在《大教堂与市集》中写下了这场运动的宣言，同时他还是《新黑客词典》的编辑。
序
Part Ⅰ Context
1 哲学
1.1 文化？什么文化
1.2 Unix的生命力
1.3 反对学习Unix文化的理由
1.4 Unix之失
1.5 Unix之得
1.6 Unix哲学基础
1.7 Unix哲学之一言以蔽之
1.8 应用Unix哲学
1.9 态度也要紧
2 历史——双流记
2.1 Unix的起源及历史，1969—1995
2.2 黑客的起源和历史：1961—1995
2.3 开源运动：1998年及之后
2.4 Unix的历史教训
3 对比：Unix哲学同其他哲学的比较
3.1 操作系统的风格元素
3.2 操作系统的比较
3.3 种什么籽，得什么果
Part Ⅱ Design
4 模块性：保持清晰，保持简洁
4.1 封装和最佳模块大小
4.2 紧凑性和正交性
4.3 软件是多层的
4.4 程序库
4.5 Unix和面向对象语言
4.6 模块式编码
5 文本化：好协议产生好实践
5.1 文本化的重要性
5.2 数据文件元格式
5.3 应用协议设计
5.4 应用协议元格式
6 透明性：来点儿光
6.1 研究实例
6.2 为透明性和可显性而设计
6.3 为可维护性而设计
7 多道程序设计：分离进程为独立的功能
7.1 从性能调整中分离复杂度控制
7.2 Unix IPC方法的分类
7.3 要避免的问题和方法
7.4 在设计层次上的进程划分
8 微型语言：寻找歌唱的乐符
8.1 理解语言分类法
8.2 应用微型语言
8.3 设计微型语言
9 生成：提升规格说明的层次
9.1 数据驱动编程
9.2 专用代码的生成
10 配置：迈出正确的第一步
10.1 什么应是可配置的
10.2 配置在哪里
10.3 运行控制文件
10.4 环境变量
10.5 命令行选项
10.6 如何挑选方法
10.7 论打破规则
11 接口：Unix环境下的用户接口设计模式
11.1 最小立异原则的应用
11.2 Unix接口设计的历史
11.3 接口设计评估
11.4 CLI和可视接口之间的权衡
11.5 透明、表现力和可配置
11.6 Unix接口设计模式
11.7 应用Unix接口设计模式
11.8 网页浏览器作为通用前端
11.9 沉默是金
12 优化
12.1 什么也别做，就站在那儿
12.2 先估量，后优化
12.3 非定域性之害
12.4 吞吐量和延迟
13 复杂度：尽可能简单，但别简单过了头
13.1 谈谈复杂度
13.2 五个编辑器的故事
13.3 编辑器的适当规模
13.4 软件的适度规模
Part Ⅲ Implementation
14 语言：C还是非C
14.1 Unix下语言的丰饶
14.2 为什么不是C
14.3 解释型语言和混合策略
14.4 语言评估
14.5 未来趋势
14.6 选择X工具包
15 工具：开发的战术
15.1 开发者友好的操作系统
15.2 编辑器选择
15.3 专用代码生成器
15.4 make：自动化编译
15.5 版本控制系统
15.6 运行期调试
15.7 性能分析
15.8 使用Emacs整合工具
16 重用：论不要重新发明轮子
16.1 猪小兵的故事
16.2 透明性是重用的关键
16.3 从重用到开源
16.4 生命中最美好的就是“开放”
16.5 何处找
16.6 使用开源软件的问题
16.7 许可证问题
Part Ⅳ Community
17 可移植性：软件可移植性与遵循标准
17.1 C语言的演化
17.2 Unix标准
17.3 IETF和RFC标准化过程
17.4 规格DNA，代码RNA
17.5 可移植性编程
17.6 国际化
17.7 可移植性、开放标准以及开放源码
18 文档：向网络世界阐释代码
18.1 文档概念
18.2 Unix风格
18.3 各种Unix文档格式
18.4 当前的混乱和可能的出路
18.5 DocBook
18.6 编写Unix文档的最佳实践
19 开放源码：在Unix新社区中编程
19.1 Unix和开放源码
19.2 与开源开发者协同工作的最佳实践
19.3 许可证的逻辑：如何挑选
19.4 为什么应使用某个标准许可证
19.5 各种开源许可证
20 未来：危机与机遇
20.1 Unix传统中的平质和偶然
20.2 Plan 9：未来之路
20.3 Unix设计中的问题
20.4 Unix的环境问题
20.5 Unix文化中的问题
20.6 信任的理由
附录A 缩写词表
附录B 参考文献
附录C 贡献者
附录D 无根的根：无名师的Unix心传
Colophon
索引
· · · · · · (收起)
原文摘录:
模块化代码的首要特质就是封装。封装良好的模块不会过多向外部披露自身的细节，不会直接调用其他模块的实现代码，也不会胡乱共享全局数据。模块之间通过应用程序变成接口（API）——一组严密、定义良好的程序调用和数据结构来通信。这就是模块化原则的内容。
有一种很好的方式来验证API是否设计良好：如果是这用纯人类语言描述设计（不许摘录任何源代码），能否把事情说清楚？养成在编码前为API编写一段非正式书面描述的习惯，是一个非常好的办法。实际上，一些最有能力的开发者，一开始总是定义接口，然后编写解药的注释，对其进行描述，最后才编写代码——因为编写注释的过程就是阐明了代码必须要到的目的。这种描述能够帮助你组织思路，本身就是十分有用的模块说明，而且，最终要可能还想把这些说明做成路标文档，方便以后的人阅读代码。 (查看原文)
henry
3赞
2012-08-03 20:51:26
—— 引自第85页
不要重复自身（Don’t Repeat Yourself），意思是说：任何一个知识点在系统内都应当有一个唯一、明确、权威的表述。在本书中，我们更愿意根据Brain Kernighan的建议，把这个远程称为“真理的单点性（Single Point Of Truth）“或者SPOT原则
数据结构也存在类似的SPOT原则：”无垃圾，无混淆（No junk, no confusion）“。”无垃圾“是说数据结构（模型）应该最小化，比如不要让数据结构太通用，居然还能表示不可能存在的情况。”无混淆“是指在真实世界中绝对明确清晰的状态在模型中也应该同样明确清晰。简言之，SPOT原则就是提倡寻找一种数据结构，使得模型中状态跟真实世界系统的状态能够一一对应。 (查看原文)
henry
1赞
2012-08-10 15:03:19
—— 引自第91页