您当前的位置：首页 > UNIX编程艺术 （美）理曼德（Raymond, E.S.）著 > 下载地址2
UNIX编程艺术 （美）理曼德（Raymond, E.S.）著
- 名 称：UNIX编程艺术 （美）理曼德（Raymond, E.S.）著 - 下载地址2
- 类 别：计算机与网络
- 下载地址：[下载地址2]
- 提 取 码：
- 浏览次数：3
发表评论 加入收藏夹 错误报告目录| 新闻评论（共有 0 条评论） |
资料介绍
UNIX编程艺术
作者： （美）理曼德（Raymond, E.S.）著
出版时间： 2006
内容简介
本书的作者将Unix三十年中未见纸端的艰难胜利的软件工程智慧熔入文字。使Unix家庭成为最最具创新软件的哲学、设计模式、工具、文化和传统，Raymond将之第一次带给我们，并向我们展示它们如何影响当今的Linux和开源运动。通过大量来自顶尖项目的实例，你将学会如何运用这些智慧经验来建造更优雅、更可移植、更加好用的更加长久的软件。 本书主要介绍了Unix系统领域中的设计和开发哲学、思想文化体系、原则与经验，由公认的Unix编程大师、开源运动领袖人物之一Eric S．Raymond倾力多年写作而成。包括Unix设计者在内的多位领域专家也为本书贡献了宝贵的内容。本书内容涉及社群文化、软件开发设计与实现，覆盖面广、内容深邃，完全展现了作者极其深厚的经验积累和领域智慧。 作者不仅给出了很多在程序设计方面的宝贵经验，还讲述了UNIX的历史，预测未来的唯一方法就是研究历史.而在目前的计算机领域，关于计算机历史的书籍和资料真是少的可怜.而且阅读此书时让人感觉正在同你讲话的是一位长者，而不仅仅是一位教师，所以这本书我一定要买。――网友正所谓“功夫在诗外”，并不能为了编程而编程（更多地为了求生，嘻嘻），而应该为了艺术而编程，这样才能从编程之外发现许多可以借鉴并让编程成为艺术的灵感，例如，当前来自于建筑学的设计模式就是一例。或许，当我们真正为艺术而编程的时候，也就往往开始迈出了从普通工匠到艺术家大师的征途，这大概就是影响了一代又一代Knuth大师的本意之所在吧。――何源
目录
序
第一篇
1 哲学
1.1 文化？什么文化？
1.2 Unix 的生命力
1.3 反对学习Unix 文化的理由
1.4 Unix 之失
1.5 Unix 之得
1.5.1 开源软件
1.5.2 跨平台可移植性和开放标准
1.5.3 Internet 和万维网
1.5.4 开源社区
1.5.5 从头到脚的灵活性
1.5.6 Unix Hack 之趣
1.5.7 Unix 的经验别处也可适用
1.6 Unix 哲学基础
1.6.1 模块原则：使用简洁的接口拼合简单的部件
1.6.2 清晰原则: 清晰胜于机巧
1.6.3 组合原则：设计时考虑拼接组合
1.6.4 分离原则: 策略同机制分离，接口同引擎分离
1.6.5 简洁原则：设计要简洁，复杂度能低则低
目录
UNIX 编程艺术
1.6.6 吝啬原则: 除非确无它法，不要编写庞大的程序
1.6.7 透明性原则：设计要可见，以便审查和调试
1.6.8 健壮原则: 健壮源于透明与简洁
1.6.9 表示原则: 把知识叠入数据以求逻辑质朴而健壮
1.6.10 通俗原则：接口设计避免标新立异
1.6.11 缄默原则：如果一个程序没什么好说的，就保持沉默
1.6.12 补救原则: 出现异常时，马上退出并给出足量错误信息
1.6.13 经济原则: 宁花机器一分，不花程序员一秒
1.6.14 生成原则: 避免手工hack，尽量编写程序去生成程序
1.6.15 优化原则: 雕琢前先得有原型，跑之前先学会走
1.6.16 多样原则:决不相信所谓“不二法门”的断言
1.6.17 扩展原则: 设计着眼未来，未来总比预想快
1.7 Unix 哲学之一言以蔽之
1.8 应用Unix 哲学
1.9 态度也要紧
2 历史——双流记
2.1 Unix 的起源及历史，1969-1995
2.1.1 创世纪：1969－1971
2.1.2 出埃及记：1971－1980
2.1.3 TCP/IP 和Unix 内战：1980－1990
2.1.4 反击帝国：1991－1995
2.2 黑客的起源和历史：1961－1995
2.2.1 游戏在校园的林间：1961－1980
2.2.2 互联网大融合与自由软件运动：1981－1991
2.2.3 Linux 和实用主义者的应对：1991－1998
2.3 开源运动：1998 年及之后
目录
AOSD 中文版—— 基于用例的面向方面软件开发
2.4 Unix 的历史教训
3 对比： Unix 哲学同其他哲学的比较
3.1 操作系统的风格元素
3.1.1 什么是Unix 操作系统的统一性理念？
3.1.2 多任务能力
3.1.3 协作进程
3.1.4 内部边界
3.1.5 文件属性和记录结构
3.1.6 二进制文件格式
3.1.7 首选用户界面风格
3.1.8 目标受众
3.1.9 开发的门坎
3.2 操作系统的比较
3.2.1 VMS
3.2.2 MacOS
3.2.3 OS/2
3.2.4 Windows NT
3.2.5 BeOS
3.2.6 MVS
3.2.7 VM/CMS
3.2.8 Linux
3.3 种什么籽，得什么果
第二篇
4 模块性：保持清晰，保持简洁
4.1 封装和最佳模块大小
4.2 紧凑性和正交性
4.2.1 紧凑性
4.2.2 正交性
4.2.3 SPOT 原则
4.2.4 紧凑性和强单一中心
4.2.5 分离的价值
4.3 软件是多层的
4.3.1 自顶向下和自底向上
4.3.2 胶合层
4.3.3 实例分析：被视为薄胶合层的C 语言
目录
UNIX 编程艺术
4.4 程序库
4.4.1 实例分析：GIMP 插件
4.5 Unix 和面向对象语言
4.6 模块式编码
5 文本化：好协议产生好实践
5.1 文本化的重要性
5.1.1 实例分析：Unix 口令文件格式
5.1.2 实例分析：.newsrc 格式
5.1.3 实例分析：PNG 图形文件格式
5.2 数据文件元格式
5.2.1 DSV 风格
5.2.2 RFC 822 格式
5.2.3 Cookie-Jar 格式
5.2.4 Record-Jar 格式
5.2.5 XML
5.2.6 Windows INI 格式
5.2.7 Unix 文本文件格式的约定
5.2.8 文件压缩的利弊
5.3 应用协议设计
5.3.1 实例分析：SMTP，一个简单的套接字协议
5.3.2 实例分析：POP3，邮局协议
5.3.3 实例分析：IMAP，互联网消息访问协议
5.4 应用协议元格
5.4.1 经典的互联网应用元协议
5.4.2 作为通用应用协议的HTTP
5.4.2.1 实例分析：CDDB/freedb.org 数据库
5.4.2.2 实例分析：互联网打印协议
5.4.3 BEEP：块可扩展交换协议
5.4.4 XML-RPC，SOAP 和Jabber
6 透明性：来点儿光
6.1 研究实例
6.1.1 实例分析：audacity
6.1.2 实例分析：fetchmail 的–v 选项
6.1.3 实例分析：GCC
6.1.4 实例分析：kmail
6.1.5 实例分析：SNG
6.1.6 实例分析：Terminfo 数据库
6.1.7 实例分析：Freeciv 数据文件
目录
AOSD 中文版—— 基于用例的面向方面软件开发
6.2 为透明性和可显性而设计
6.2.1 透明性中的之禅
6.2.2 为透明性和可显性而编码
6.2.3 透明性和避免过度保护
6.2.4 透明性和可编辑的表现形式表达
6.2.5 透明性、故障诊断和故障恢复
6.3 为可维护性而设计
7 多道程序设计： 分离进程为独立的功能
7.1 从性能调整中分离复杂度控制
7.2 Unix IPC 方法的分类
7.2.1 把任务转给专门程序
7.2.2 管道、重定向和过滤器
7.2.3 包装器
7.2.4 安全性包装器和Bernstein 链
7.2.5 从进程
7.2.6 对等进程间通信
7.3 要避免的问题和方法
7.3.1 废弃的Unix IPC 方法
7.3.2 远程过程调用
7.3.3 线程——恐吓或威胁？
7.4 在设计层次上的进程划分
8 微型语言：寻找歌唱的乐符
8.1 理解语言分类法
8.2 应用微型语言
8.2.1 案例分析：sng
8.2.2 案例分析：正则表达式
8.2.3 案例分析：Glade
8.2.4 案例分析：m4
8.2.5 案例分析：XSLT
8.2.6 案例分析：The Documenter's Workbench Tools
8.2.7 案例分析：fetchmail 的运行控制语法
8.2.8 案例分析：awk
8.2.9 案例分析：PostScript
8.2.10 案例分析：bc 和dc
8.2.11 案例分析：Emacs Lisp
8.2.12 案例分析：JavaScript
8.3 设计微型语言
目录
UNIX 编程艺术
8.3.1 选择正确的复杂度
8.3.2 扩展和嵌入语言
8.3.3 编写自定义语法
8.3.4 宏—慎用！
8.3.5 语言还是应用协议？
9 生成：提升规格说明的层次
9.1 数据驱动编程
9.1.1 实例分析：ascii
9.1.2 实例分析：统计学的垃圾邮件统计
9.1.3 实例分析：fetchmailconf 中的元类改动
9.2 专用代码的生成
9.2.1 实例分析：生成ascii 显示的代码
9.2.2 实例分析：为列表生成HTML 代码
10 配置：迈出正确的第一步
10.1 什么应是可配置的？
10.2 配置在哪里
10.3 运行控制文件
10.3.1 实例分析：.netrc 文件
10.3.2 到其它操作系统的可移植性
10.4 环境变量
10.4.1 系统环境变量
10.4.2 用户环境变量
10.4.3 何时使用环境变量
10.4.4 到其它操作系统的可移植性
10.5 命令行选项
10.5.1 从–a 到–z 的命令行选项
10.5.2 到其它操作系统的可移植性
10.6 如何挑选方法
10.6.1 实例分析：fetchmail
10.6.2 实例分析：XFree86 服务器
10.7 论打破规则
11 接口：Unix 环境下的用户接口设计模式
11.1 最小立异原则的应用
11.2 Unix 接口设计的历史
目录
AOSD 中文版—— 基于用例的面向方面软件开发
11.3 接口设计评估
11.4 CLI 和可视接口之间的权衡
11.4.1 实例分析：编写计算器程序的两种方式
11.5 透明度、表现力和可配置性
11.6 Unix 接口设计模式
11.6.1 过滤器模式
11.6.2 Cantrip 模式
11.6.3 源模式
11.6.4 接收器模式
11.6.5 编译器模式
1.6.6 ed 模式
11.6.7 Roguelike 模式
11.6.8 “引擎和接口分离”模式
11.6.9 CLI 服务器模式
11.7 应用Unix 接口设计模式
11.8 网页浏览器作为通用前端
11.9 沉默是金
12 优化
12.1 什么也别做，就站在那儿！
12.2 先估量，后优化
12.3 非定域性之害
12.4 吞吐量和延迟
12.4.1 批操作
12.4.2 重叠操作
12.4.3 缓存操作结果
13.1 谈谈复杂度
13.1.1 复杂度的三个来源
13.1.2 接口复杂度和实现复杂度的折衷
13.1.3 必然的、可能的和偶然的复杂度
13.1.4 映射复杂度
目录
UNIX 编程艺术
13.1.5 当简洁性不能胜任
13.2 五个编辑器的故事
13.2.1 ed
13.2.2 vi.
13.2.3 Sam
13.2.4 Emacs
13.2.5 Wily
13.3 编辑器的适当规模
13.3.1 甄别复杂度问题
13.3.2 折衷无用
13.3.3 Emacs 是个反Unix 传统的论据吗？
13.4 软件的适度规模
第一篇
14 语言：C 还是非C？
14.1 Unix 下语言的丰饶
14.2 为什么不是C？
14.3 解释型语言和混合策略
14.4 语言评估
14.4.1 C
14.4.2 C++
14.4.3 Shell
14.4.4 Perl
14.4.5 Tcl.
14.4.6 Python
14.4.7 Java
14.4.8 Emacs Lisp
14.5 未来趋势
14.6 选择X 工具包
15 工具：开发的战术
15.1 开发者友好的操作系统
15.2 编辑器选择
15.2.1 了解vi
目录
AOSD 中文版—— 基于用例的面向方面软件开发
15.2.2 了解Emacs
15.2.3 非虔诚的选择：两者兼用
15.3 专用代码生成器
15.3.1 yacc 和lex
15.3.1 实例分析：fetchmailrc 的语法
15.3.2 实例分析：Glade
15.4 make：自动化编译
15.4.1 make 的基本理论
15.4.2 非C/C++开发中的make
15.4.3 通用生成目标
15.4.4 生成Makefile
15.5 版本控制系统
15.5.1 为什么需要版本控制？
15.5.2 手工版本控制
15.5.3 自动化的版本控制
15.5.4 Unix 的版本控制工具
15.6 运行期调试
15.7 性能分析
15.8 使用Emacs 整合工具
15.8.1 Emacs 和make
15.8.2 Emacs 和运行期调试
15.8.3 Emacs 和版本控制
15.8.4 Emacs 和Profiling
15.8.5 像IDE 一样，但更强
16 重用：论不要重新发明轮子
——《道德经》
16.1 猪小兵的故事
16.2 透明性是重用的关键
16.3 从重用到开源
16.4 生命中最美好的就是“开放”
16.5 何处找？
16.6 使用开源软件的问题
16.7 许可证问题
16.7.1 开放源码的资格
16.7.2 标准开放源码许可证
16.7.3 何时需要律师
目录
UNIX 编程艺术
第一篇
17 可移植性：软件可移植性与遵循标准
17.1 C 语言的演化
17.1.1 早期的C 语言
17.2.1 C 语言标准
17.2 Unix 标准
17.2.1 标准和Unix 之战
17.2.2 庆功宴上的幽灵
17.2.3 开源世界的Unix 标准
17.3 IETF 和RFC 标准化过程
17.4 规格DNA，代码RNA
17.5 可移植性编程
17.5.1 可移植性和编程语言选择
17.5.2 避免系统依赖性
17.5.3 移植工具
17.6 国际化
17.7 可移植性、开放标准以及开放源码
18 文档：向网络的世界阐释代码
18.1 文档概念
18.2 Unix 风格
18.2.1 大文档偏爱
18.2.2 文化风格
18.3 各种Unix 文档格式
18.3.1 troff 和Documenter's Workbench Tools
18.3.2 TEX
18.3.3 Texinfo
18.3.4 POD
18.3.5 HTML
18.3.6 DocBook
18.4 当前的混乱和可能的出路
18.5 DocBook
18.5.1 文档类型定义
18.5.2 其它DTD
目录
AOSD 中文版—— 基于用例的面向方面软件开发
18.5.3 DocBook 工具链
18.5.4 移植工具
GNU Texinfo
POD
LATEX
18.5.5 编辑工具
18.5.6 相关标准和实践
18.5.7 SGML
18.5.8 XML-DocBook 参考书籍
18.6 编写Unix 文档的最佳实践
19 开放源码：在Unix 新社区中编程
19.1 Unix 和开放源码
19.2 与开源开发者协同工作的最佳实践
19.2.1 良好的修补实践
19.2.2 良好的项目、档案文件命名实践
19.2.3 良好的开发实践
19.2.4 良好的发行制作实践
19.2.5 良好的交流实践
19.3 许可证的逻辑：如何挑选
19.4 为什么应使用某个标准许可证
19.5 各种开源许可证
19.5.1 MIT 或者X Consortium 许可证
19.5.2 经典BSD 许可证
19.5.3 Artistic 许可证
19.5.4 通用公共许可证
19.5.5 Mozilla 公共许可证
20 未来：危机与机遇
20.1 Unix 传统中的必然和偶然
20.2 Plan 9：未来之路
20.3 Unix 设计中的问题
20.3.1 Unix 文件就是一大袋字节
20.3.2 Unix 对GUI 的支持孱弱
20.3.3 文件删除不可撤销
20.3.4 Unix 假定文件系统是静态的
20.3.5 作业控制设计拙劣
20.3.6 Unix API 没有使用异常
20.3.7 ioctl(2)和fcntl(2)是个尴尬
20.3.8 Unix 安全模型可能太过原始
20.3.9 Unix 名字种类太多
目录
UNIX 编程艺术
20.3.10 文件系统可能有害论
20.3.11 朝向全局互联网地址空间
20.4 Unix 的环境问题
20.5 Unix 文化中的问题
20.6 信任的理由
附录A 缩写词表
附录C 贡献者
附录D 无根的根：无名师的Unix 心传
索引
作者： （美）理曼德（Raymond, E.S.）著
出版时间： 2006
内容简介
本书的作者将Unix三十年中未见纸端的艰难胜利的软件工程智慧熔入文字。使Unix家庭成为最最具创新软件的哲学、设计模式、工具、文化和传统，Raymond将之第一次带给我们，并向我们展示它们如何影响当今的Linux和开源运动。通过大量来自顶尖项目的实例，你将学会如何运用这些智慧经验来建造更优雅、更可移植、更加好用的更加长久的软件。 本书主要介绍了Unix系统领域中的设计和开发哲学、思想文化体系、原则与经验，由公认的Unix编程大师、开源运动领袖人物之一Eric S．Raymond倾力多年写作而成。包括Unix设计者在内的多位领域专家也为本书贡献了宝贵的内容。本书内容涉及社群文化、软件开发设计与实现，覆盖面广、内容深邃，完全展现了作者极其深厚的经验积累和领域智慧。 作者不仅给出了很多在程序设计方面的宝贵经验，还讲述了UNIX的历史，预测未来的唯一方法就是研究历史.而在目前的计算机领域，关于计算机历史的书籍和资料真是少的可怜.而且阅读此书时让人感觉正在同你讲话的是一位长者，而不仅仅是一位教师，所以这本书我一定要买。――网友正所谓“功夫在诗外”，并不能为了编程而编程（更多地为了求生，嘻嘻），而应该为了艺术而编程，这样才能从编程之外发现许多可以借鉴并让编程成为艺术的灵感，例如，当前来自于建筑学的设计模式就是一例。或许，当我们真正为艺术而编程的时候，也就往往开始迈出了从普通工匠到艺术家大师的征途，这大概就是影响了一代又一代Knuth大师的本意之所在吧。――何源
目录
序
第一篇
1 哲学
1.1 文化？什么文化？
1.2 Unix 的生命力
1.3 反对学习Unix 文化的理由
1.4 Unix 之失
1.5 Unix 之得
1.5.1 开源软件
1.5.2 跨平台可移植性和开放标准
1.5.3 Internet 和万维网
1.5.4 开源社区
1.5.5 从头到脚的灵活性
1.5.6 Unix Hack 之趣
1.5.7 Unix 的经验别处也可适用
1.6 Unix 哲学基础
1.6.1 模块原则：使用简洁的接口拼合简单的部件
1.6.2 清晰原则: 清晰胜于机巧
1.6.3 组合原则：设计时考虑拼接组合
1.6.4 分离原则: 策略同机制分离，接口同引擎分离
1.6.5 简洁原则：设计要简洁，复杂度能低则低
目录
UNIX 编程艺术
1.6.6 吝啬原则: 除非确无它法，不要编写庞大的程序
1.6.7 透明性原则：设计要可见，以便审查和调试
1.6.8 健壮原则: 健壮源于透明与简洁
1.6.9 表示原则: 把知识叠入数据以求逻辑质朴而健壮
1.6.10 通俗原则：接口设计避免标新立异
1.6.11 缄默原则：如果一个程序没什么好说的，就保持沉默
1.6.12 补救原则: 出现异常时，马上退出并给出足量错误信息
1.6.13 经济原则: 宁花机器一分，不花程序员一秒
1.6.14 生成原则: 避免手工hack，尽量编写程序去生成程序
1.6.15 优化原则: 雕琢前先得有原型，跑之前先学会走
1.6.16 多样原则:决不相信所谓“不二法门”的断言
1.6.17 扩展原则: 设计着眼未来，未来总比预想快
1.7 Unix 哲学之一言以蔽之
1.8 应用Unix 哲学
1.9 态度也要紧
2 历史——双流记
2.1 Unix 的起源及历史，1969-1995
2.1.1 创世纪：1969－1971
2.1.2 出埃及记：1971－1980
2.1.3 TCP/IP 和Unix 内战：1980－1990
2.1.4 反击帝国：1991－1995
2.2 黑客的起源和历史：1961－1995
2.2.1 游戏在校园的林间：1961－1980
2.2.2 互联网大融合与自由软件运动：1981－1991
2.2.3 Linux 和实用主义者的应对：1991－1998
2.3 开源运动：1998 年及之后
目录
AOSD 中文版—— 基于用例的面向方面软件开发
2.4 Unix 的历史教训
3 对比： Unix 哲学同其他哲学的比较
3.1 操作系统的风格元素
3.1.1 什么是Unix 操作系统的统一性理念？
3.1.2 多任务能力
3.1.3 协作进程
3.1.4 内部边界
3.1.5 文件属性和记录结构
3.1.6 二进制文件格式
3.1.7 首选用户界面风格
3.1.8 目标受众
3.1.9 开发的门坎
3.2 操作系统的比较
3.2.1 VMS
3.2.2 MacOS
3.2.3 OS/2
3.2.4 Windows NT
3.2.5 BeOS
3.2.6 MVS
3.2.7 VM/CMS
3.2.8 Linux
3.3 种什么籽，得什么果
第二篇
4 模块性：保持清晰，保持简洁
4.1 封装和最佳模块大小
4.2 紧凑性和正交性
4.2.1 紧凑性
4.2.2 正交性
4.2.3 SPOT 原则
4.2.4 紧凑性和强单一中心
4.2.5 分离的价值
4.3 软件是多层的
4.3.1 自顶向下和自底向上
4.3.2 胶合层
4.3.3 实例分析：被视为薄胶合层的C 语言
目录
UNIX 编程艺术
4.4 程序库
4.4.1 实例分析：GIMP 插件
4.5 Unix 和面向对象语言
4.6 模块式编码
5 文本化：好协议产生好实践
5.1 文本化的重要性
5.1.1 实例分析：Unix 口令文件格式
5.1.2 实例分析：.newsrc 格式
5.1.3 实例分析：PNG 图形文件格式
5.2 数据文件元格式
5.2.1 DSV 风格
5.2.2 RFC 822 格式
5.2.3 Cookie-Jar 格式
5.2.4 Record-Jar 格式
5.2.5 XML
5.2.6 Windows INI 格式
5.2.7 Unix 文本文件格式的约定
5.2.8 文件压缩的利弊
5.3 应用协议设计
5.3.1 实例分析：SMTP，一个简单的套接字协议
5.3.2 实例分析：POP3，邮局协议
5.3.3 实例分析：IMAP，互联网消息访问协议
5.4 应用协议元格
5.4.1 经典的互联网应用元协议
5.4.2 作为通用应用协议的HTTP
5.4.2.1 实例分析：CDDB/freedb.org 数据库
5.4.2.2 实例分析：互联网打印协议
5.4.3 BEEP：块可扩展交换协议
5.4.4 XML-RPC，SOAP 和Jabber
6 透明性：来点儿光
6.1 研究实例
6.1.1 实例分析：audacity
6.1.2 实例分析：fetchmail 的–v 选项
6.1.3 实例分析：GCC
6.1.4 实例分析：kmail
6.1.5 实例分析：SNG
6.1.6 实例分析：Terminfo 数据库
6.1.7 实例分析：Freeciv 数据文件
目录
AOSD 中文版—— 基于用例的面向方面软件开发
6.2 为透明性和可显性而设计
6.2.1 透明性中的之禅
6.2.2 为透明性和可显性而编码
6.2.3 透明性和避免过度保护
6.2.4 透明性和可编辑的表现形式表达
6.2.5 透明性、故障诊断和故障恢复
6.3 为可维护性而设计
7 多道程序设计： 分离进程为独立的功能
7.1 从性能调整中分离复杂度控制
7.2 Unix IPC 方法的分类
7.2.1 把任务转给专门程序
7.2.2 管道、重定向和过滤器
7.2.3 包装器
7.2.4 安全性包装器和Bernstein 链
7.2.5 从进程
7.2.6 对等进程间通信
7.3 要避免的问题和方法
7.3.1 废弃的Unix IPC 方法
7.3.2 远程过程调用
7.3.3 线程——恐吓或威胁？
7.4 在设计层次上的进程划分
8 微型语言：寻找歌唱的乐符
8.1 理解语言分类法
8.2 应用微型语言
8.2.1 案例分析：sng
8.2.2 案例分析：正则表达式
8.2.3 案例分析：Glade
8.2.4 案例分析：m4
8.2.5 案例分析：XSLT
8.2.6 案例分析：The Documenter's Workbench Tools
8.2.7 案例分析：fetchmail 的运行控制语法
8.2.8 案例分析：awk
8.2.9 案例分析：PostScript
8.2.10 案例分析：bc 和dc
8.2.11 案例分析：Emacs Lisp
8.2.12 案例分析：JavaScript
8.3 设计微型语言
目录
UNIX 编程艺术
8.3.1 选择正确的复杂度
8.3.2 扩展和嵌入语言
8.3.3 编写自定义语法
8.3.4 宏—慎用！
8.3.5 语言还是应用协议？
9 生成：提升规格说明的层次
9.1 数据驱动编程
9.1.1 实例分析：ascii
9.1.2 实例分析：统计学的垃圾邮件统计
9.1.3 实例分析：fetchmailconf 中的元类改动
9.2 专用代码的生成
9.2.1 实例分析：生成ascii 显示的代码
9.2.2 实例分析：为列表生成HTML 代码
10 配置：迈出正确的第一步
10.1 什么应是可配置的？
10.2 配置在哪里
10.3 运行控制文件
10.3.1 实例分析：.netrc 文件
10.3.2 到其它操作系统的可移植性
10.4 环境变量
10.4.1 系统环境变量
10.4.2 用户环境变量
10.4.3 何时使用环境变量
10.4.4 到其它操作系统的可移植性
10.5 命令行选项
10.5.1 从–a 到–z 的命令行选项
10.5.2 到其它操作系统的可移植性
10.6 如何挑选方法
10.6.1 实例分析：fetchmail
10.6.2 实例分析：XFree86 服务器
10.7 论打破规则
11 接口：Unix 环境下的用户接口设计模式
11.1 最小立异原则的应用
11.2 Unix 接口设计的历史
目录
AOSD 中文版—— 基于用例的面向方面软件开发
11.3 接口设计评估
11.4 CLI 和可视接口之间的权衡
11.4.1 实例分析：编写计算器程序的两种方式
11.5 透明度、表现力和可配置性
11.6 Unix 接口设计模式
11.6.1 过滤器模式
11.6.2 Cantrip 模式
11.6.3 源模式
11.6.4 接收器模式
11.6.5 编译器模式
1.6.6 ed 模式
11.6.7 Roguelike 模式
11.6.8 “引擎和接口分离”模式
11.6.9 CLI 服务器模式
11.7 应用Unix 接口设计模式
11.8 网页浏览器作为通用前端
11.9 沉默是金
12 优化
12.1 什么也别做，就站在那儿！
12.2 先估量，后优化
12.3 非定域性之害
12.4 吞吐量和延迟
12.4.1 批操作
12.4.2 重叠操作
12.4.3 缓存操作结果
13.1 谈谈复杂度
13.1.1 复杂度的三个来源
13.1.2 接口复杂度和实现复杂度的折衷
13.1.3 必然的、可能的和偶然的复杂度
13.1.4 映射复杂度
目录
UNIX 编程艺术
13.1.5 当简洁性不能胜任
13.2 五个编辑器的故事
13.2.1 ed
13.2.2 vi.
13.2.3 Sam
13.2.4 Emacs
13.2.5 Wily
13.3 编辑器的适当规模
13.3.1 甄别复杂度问题
13.3.2 折衷无用
13.3.3 Emacs 是个反Unix 传统的论据吗？
13.4 软件的适度规模
第一篇
14 语言：C 还是非C？
14.1 Unix 下语言的丰饶
14.2 为什么不是C？
14.3 解释型语言和混合策略
14.4 语言评估
14.4.1 C
14.4.2 C++
14.4.3 Shell
14.4.4 Perl
14.4.5 Tcl.
14.4.6 Python
14.4.7 Java
14.4.8 Emacs Lisp
14.5 未来趋势
14.6 选择X 工具包
15 工具：开发的战术
15.1 开发者友好的操作系统
15.2 编辑器选择
15.2.1 了解vi
目录
AOSD 中文版—— 基于用例的面向方面软件开发
15.2.2 了解Emacs
15.2.3 非虔诚的选择：两者兼用
15.3 专用代码生成器
15.3.1 yacc 和lex
15.3.1 实例分析：fetchmailrc 的语法
15.3.2 实例分析：Glade
15.4 make：自动化编译
15.4.1 make 的基本理论
15.4.2 非C/C++开发中的make
15.4.3 通用生成目标
15.4.4 生成Makefile
15.5 版本控制系统
15.5.1 为什么需要版本控制？
15.5.2 手工版本控制
15.5.3 自动化的版本控制
15.5.4 Unix 的版本控制工具
15.6 运行期调试
15.7 性能分析
15.8 使用Emacs 整合工具
15.8.1 Emacs 和make
15.8.2 Emacs 和运行期调试
15.8.3 Emacs 和版本控制
15.8.4 Emacs 和Profiling
15.8.5 像IDE 一样，但更强
16 重用：论不要重新发明轮子
——《道德经》
16.1 猪小兵的故事
16.2 透明性是重用的关键
16.3 从重用到开源
16.4 生命中最美好的就是“开放”
16.5 何处找？
16.6 使用开源软件的问题
16.7 许可证问题
16.7.1 开放源码的资格
16.7.2 标准开放源码许可证
16.7.3 何时需要律师
目录
UNIX 编程艺术
第一篇
17 可移植性：软件可移植性与遵循标准
17.1 C 语言的演化
17.1.1 早期的C 语言
17.2.1 C 语言标准
17.2 Unix 标准
17.2.1 标准和Unix 之战
17.2.2 庆功宴上的幽灵
17.2.3 开源世界的Unix 标准
17.3 IETF 和RFC 标准化过程
17.4 规格DNA，代码RNA
17.5 可移植性编程
17.5.1 可移植性和编程语言选择
17.5.2 避免系统依赖性
17.5.3 移植工具
17.6 国际化
17.7 可移植性、开放标准以及开放源码
18 文档：向网络的世界阐释代码
18.1 文档概念
18.2 Unix 风格
18.2.1 大文档偏爱
18.2.2 文化风格
18.3 各种Unix 文档格式
18.3.1 troff 和Documenter's Workbench Tools
18.3.2 TEX
18.3.3 Texinfo
18.3.4 POD
18.3.5 HTML
18.3.6 DocBook
18.4 当前的混乱和可能的出路
18.5 DocBook
18.5.1 文档类型定义
18.5.2 其它DTD
目录
AOSD 中文版—— 基于用例的面向方面软件开发
18.5.3 DocBook 工具链
18.5.4 移植工具
GNU Texinfo
POD
LATEX
18.5.5 编辑工具
18.5.6 相关标准和实践
18.5.7 SGML
18.5.8 XML-DocBook 参考书籍
18.6 编写Unix 文档的最佳实践
19 开放源码：在Unix 新社区中编程
19.1 Unix 和开放源码
19.2 与开源开发者协同工作的最佳实践
19.2.1 良好的修补实践
19.2.2 良好的项目、档案文件命名实践
19.2.3 良好的开发实践
19.2.4 良好的发行制作实践
19.2.5 良好的交流实践
19.3 许可证的逻辑：如何挑选
19.4 为什么应使用某个标准许可证
19.5 各种开源许可证
19.5.1 MIT 或者X Consortium 许可证
19.5.2 经典BSD 许可证
19.5.3 Artistic 许可证
19.5.4 通用公共许可证
19.5.5 Mozilla 公共许可证
20 未来：危机与机遇
20.1 Unix 传统中的必然和偶然
20.2 Plan 9：未来之路
20.3 Unix 设计中的问题
20.3.1 Unix 文件就是一大袋字节
20.3.2 Unix 对GUI 的支持孱弱
20.3.3 文件删除不可撤销
20.3.4 Unix 假定文件系统是静态的
20.3.5 作业控制设计拙劣
20.3.6 Unix API 没有使用异常
20.3.7 ioctl(2)和fcntl(2)是个尴尬
20.3.8 Unix 安全模型可能太过原始
20.3.9 Unix 名字种类太多
目录
UNIX 编程艺术
20.3.10 文件系统可能有害论
20.3.11 朝向全局互联网地址空间
20.4 Unix 的环境问题
20.5 Unix 文化中的问题
20.6 信任的理由
附录A 缩写词表
附录C 贡献者
附录D 无根的根：无名师的Unix 心传
索引
