UNIX哲学

UNIX编程艺术

序

Part I

第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 简洁原则：设计要简洁，复杂度能低则低

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年及之后

2.4 Unix的历史教训

第3章 对比：Unix哲学同其他哲学的比较

3.1 操作系统的风格元素

3.1.1 什么是操作系统的统一性理念

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 种什么籽，得什么果

Part II

第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语言

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.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数据文件

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 设计微型语言

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环境下的用户接口设计模式

第12章 优化

第13章 复杂度：尽可能简单，但别简单过了头

Part Ⅲ

第14章 语言：C还是非C

第15章 工具：开发的战术

第16章 重用：论不要重新发明轮子

Part Ⅳ

第17章 可移植性：软件可移植性与遵循标准

第18章 文档：向网络世界阐释代码

第19章 开放源码：在Unix新社区中编程

第20章 未来：危机与机遇

附录A 缩写词表

附录B 参考文献

附录C 贡献者

附录D 无根的根：无名师的Unix心传

Colophon

索引

读者评论

 

=====================

Douglas McIlroy是Unix系统上管道机制的发明者，也是Unix文化的缔造者之一。他归纳的Unix哲学如下：

程序应该只关注一个目标，并尽可能把它做好。让程序能够互相协同工作。应该让程序处理文本数据流，因为这是一个通用的接口。

 

罗勃·派克在他的《Notes on Programming in C》中提到了以下格言。虽然这些规则是关于程序设计的，但作为Unix哲学丝毫不为过：

规则一：你永远不会知道你的程序会在什么地方耗费时间。程序的瓶颈常常出现在意想不到的地方，因此在你确信找到瓶颈后再动手优化代码吧。

规则二：测试代码。只有在你详细测试了代码，并且发现一部分代码耗费了绝大部分的运行时间时再对程序作速度优化。

规则三：功能全面的算法（fancy algorithm）在处理小规模问题时效率很低，这是因为算法时间效率中的常量很大，而问题往往规模很小。除非你知道你遇到的常常是复杂的情况，否则就让代码丑陋但是简单而高效吧。（即使问题规模确实很大，也首先尝试第二条规则。）

规则四：功能全面的算法比简单的算法更容易产生Bug，更难实现。尽量使用简单的算法和数据结构。

规则五：数据决定一切。如果选择的数据结构能很好的管理数据，算法部分往往不言自明。记住，数据结构，而非算法，才是编程的关键。

规则六：没有第六条规则。

 

 

1994年，X Window系统开发组的成员Mike Gancarz根据他自己的Unix系统经验以及和其他领域使用Unix系统的资深程序员们的讨论结果，写成了《The UNIX Philosophy》，提出了9条训格之言：

一：小即是美。

二：让程序只做好一件事。

三：尽可能早地建立原型。

四：可移植性比效率更重要。

五：数据应该保存为文本文件。

六：尽可能地榨取软件的全部价值。

七：使用shell脚本来提高效率和可移植性。

八：避免使用可定制性低下的用户界面。

九：所有程序都是数据的过滤器。

此外还有十条原则则并不为所有人认同，甚至还是争论的焦点（如宏内核和微内核之争）：

一：应该允许用户定制操作环境。

二：让操作系统核心小而轻。

三：使用小写字母并尽量简短。

四：节约纸张，保护树林。

五：沉默是金。

六：并行地思考。

七：部分加部分大于整体。

八：寻找问题的帕雷托法则。

九：程序随需求而增长（Worse is better）。

十：层级地思考。

Richard P. Gabriel提议Unix的一个关键优势是他称作“糟糕的更好”的设计哲学。在“糟糕的更好”的设计风格下，接口和实现的简单性比系统的任何其他属性都更重要，包括准确性、一致性和完整性。Gabriel主张这种设计风格拥有关键的进化优势，尽管他也怀疑一些结果的质量。

=====================