UNIX编程艺术 下载 pdf 百度网盘 epub 免费 2025 电子书 mobi 在线

《UNIX编程艺术》主要介绍了Unix系统领域中的设计和开发哲学、思想文化体系、原则与经验，由公认的Unix编程大师、开源运动领袖人物之一Eric S.Raymond倾力多年写作而成。包括Unix设计者在内的多位领域专家也为《UNIX编程艺术》贡献了宝贵的内容。《UNIX编程艺术》内容涉及社群文化、软件开发设计与实现，覆盖面广、内容深邃，完全展现了作者极其深厚的经验积累和领域智慧。

序

PartIⅠ1

第1章 哲学3

1.1 文化？什么文化3

1.2 Unix的生命力4

1.3 反对学习Unix文化的理由5

1.4 Unix之失6

1.5 Unix之得7

1.5.1 开源软件7

1.5.2 跨平台可移植性和开放标准8

1.5.3 Internet和万维网8

1.5.4 开源社区9

1.5.5 从头到脚的灵活性9

1.5.6 UnixHack之趣10

1.5.7 Unix的经验别处也可适用11

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

1.7 Unix哲学之一言以蔽之25

1.8 应用Unix哲学26

1.9 态度也要紧26

第2章 历史——双流记29

2.1 Unix的起源及历史，1969－199529

2.1.1 创世纪：1969－197130

2.1.2 出埃及记：1971－198032

2.1.3 TCP/IP和Unix内战：1980－199035

2.1.4 反击帝国：1991－199541

2.2 黑客的起源和历史：1961－199543

2.2.1 游戏在校园的林间：1961－198044

2.2.2 互联网大融合与自由软件运动：1981－199145

2.2.3 Linux和实用主义者的应对：1991－199848

2.3 开源运动：1998年及之后49

2.4 Unix的历史教训51

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

3.1 操作系统的风格元素53

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

3.1.2 多任务能力54

3.1.3 协作进程55

3.1.4 内部边界57

3.1.5 文件属性和记录结构57

3.1.6 二进制文件格式58

3.1.7 首选用户界面风格58

3.1.8 目标受众59

3.1.9 开发的门坎60

3.2 操作系统的比较61

3.2.1 VMS61

3.2.2 MacOS64

3.2.3 OS/265

3.2.4 WindowsNT68

3.2.5 BeOS71

3.2.6 MVS72

3.2.7 VM/CMS74

3.2.8 Linux76

3.3 种什么籽，得什么果78

PartⅡ81

第4章 模块性：保持清晰，保持简洁83

4.1 封装和最佳模块大小85

4.2 紧凑性和正交性87

4.2.1 紧凑性87

4.2.2 正交性89

4.2.3 SPOT原则91

4.2.4 紧凑性和强单一中心92

4.2.5 分离的价值94

4.3 软件是多层的95

4.3.1 自顶向下和自底向上95

4.3.2 胶合层97

4.3.3 实例分析：被视为薄胶合层的C语言98

4.4 程序库99

4.4.1 实例分析：GIMP插件100

4.5 Unix和面向对象语言101

4.6 模块式编码103

第5章 文本化：好协议产生好实践105

5.1 文本化的重要性107

5.1.1 实例分析：Unix口令文件格式109

5.1.2 实例分析：newsrc格式110

5.1.3 实例分析：PNG图形文件格式111

5.2 数据文件元格式112

5.2.1 DSV风格113

5.2.2 RFC822格式114

5.2.3 Cookie—Jar格式115

5.2.4 Record—Jar格式116

5.2.5 XML117

5.2.6 WindowsINI格式119

5.2.7 Unix文本文件格式的约定120

5.2.8 文件压缩的利弊122

5.3 应用协议设计123

5.3.1 实例分析：SMTP，一个简单的套接字协议124

5.3.2 实例分析：POP3，邮局协议124

5.3.3 实例分析：IMAP，互联网消息访问协议126

5.4 应用协议元格式127

5.4.1 经典的互联网应用元协议127

5.4.2 作为通用应用协议的HTTP128

5.4.3 BEEP：块可扩展交换协议130

5.4.4 XML—RPC，SOAP和Jabber131

第6章 透明性：来点儿光133

6.1 研究实例135

6.1.1 实例分析：audacity135

6.1.2 实例分析：fetchmail的–v选项136

6.1.3 实例分析：GCC139

6.1.4 实例分析：kmail140

6.1.5 实例分析：SNG142

6.1.6 实例分析：Terminfo数据库144

6.1.7 实例分析：Freeciv数据文件146

6.2 为透明性和可显性而设计148

6.2.1 透明性之禅149

6.2.2 为透明性和可显性而编码150

6.2.3 透明性和避免过度保护151

6.2.4 透明性和可编辑的表现形式152

6.2.5 透明性、故障诊断和故障恢复153

6.3 为可维护性而设计154

第7章 多道程序设计：分离进程为独立的功能157

7.1 从性能调整中分离复杂度控制159

7.2 UnixIPC方法的分类160

7.2.1 把任务转给专门程序160

7.2.2 管道、重定向和过滤器161

7.2.3 包装器166

7.2.4 安全性包装器和Bernstein链167

7.2.5 从进程168

7.2.6 对等进程间通信169

7.3 要避免的问题和方法176

7.3.1 废弃的UnixIPC方法176

7.3.2 远程过程调用178

7.3.3 线程——恐吓或威胁180

7.4 在设计层次上的进程划分181

第8章 微型语言：寻找歌唱的乐符183

8.1 理解语言分类法185

8.2 应用微型语言187

8.2.1 案例分析：sng187

8.2.2 案例分析：正则表达式188

8.2.3 案例分析：Glade191

8.2.4 案例分析：m4193

8.2.5 案例分析：XSLT194

8.2.6 案例分析：TheDocumenter's work bench Tools195

8.2.7 案例分析：fetchmail的运行控制语法199

8.2.8 案例分析：awk200

8.2.9 案例分析：PostScript202

8.2.10 案例分析：bc和dc203

8.2.11 案例分析：EmacsLisp205

8.2.12 案例分析：JavaScript205

8.3 设计微型语言206

8.3.1 选择正确的复杂度207

8.3.2 扩展和嵌入语言209

8.3.3 编写自定义语法210

8.3.4 宏—慎用210

8.3.5 语言还是应用协议212

第9章 生成：提升规格说明的层次215

9.1 数据驱动编程216

9.1.1 实例分析：ascii217

9.1.2 实例分析：统计学的垃圾邮件统计218

9.1.3 实例分析：fetchmailconf中的元类改动219

9.2 专用代码的生成225

9.2.1 实例分析：生成ascii显示的代码225

9.2.2 实例分析：为列表生成HTML代码227

第10章 配置：迈出正确的第一步231

10.1 什么应是可配置的231

10.2 配置在哪里233

10.3 运行控制文件234

10.3.1 实例分析：.Netrc文件236

10.3.2 到其它操作系统的可移植性238

10.4 环境变量238

10.4.1 系统环境变量238

10.4.2 用户环境变量240

10.4.3 何时使用环境变量240

10.4.4 到其它操作系统的可移植性242

10.5 命令行选项242

10.5.1 从–a到–z的命令行选项243

10.5.2 到其它操作系统的可移植性248

10.6 如何挑选方法248

10.6.1 实例分析：fetchmail249

10.6.2 实例分析：XFree86服务器251

10.7 论打破规则252

第11章 接口：Unix环境下的用户接口设计模式253

11.1 最小立异原则的应用254

11.2 Unix接口设计的历史256

11.3 接口设计评估257

11.4 CLI和可视接口之间的权衡259

11.4.1 实例分析：编写计算器程序的两种方式262

11.5 透明度、表现力和可配置性264

11.6 Unix接口设计模式266

11.6.1 过滤器模式266

11.6.2 Cantrip模式268

11.6.3 源模式268

11.6.4 接收器模式269

11.6.5 编译器模式269

11.6.6 ed模式270

11.6.7 Roguelike模式270

11.6.8 “引擎和接口分离”模式273

11.6.9 CLI服务器模式278

11.6.10 基于语言的接口模式279

11.7 应用Unix接口设计模式280

11.7.1多价程序模式

11.8 网页浏览器作为通用前端281

11.9 沉默是金284

第12章 优化287

12.1 什么也别做，就站在那儿287

12.2 先估量，后优化288

12.3 非定域性之害290

12.4 吞吐量和延迟291

12.4.1 批操作292

12.4.2 重叠操作293

12.4.3 缓存操作结果293

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

13.1 谈谈复杂度296

13.1.1 复杂度的三个来源296

13.1.2 接口复杂度和实现复杂度的折中298

13.1.3 必然的、可能的和偶然的复杂度299

13.1.4 映射复杂度300

13.1.5 当简洁性不能胜任302

13.2 五个编辑器的故事302

13.2.1 ed304

13.2.2 vi305

13.2.3 Sam306

13.2.4 Emacs307

13.2.5 Wily308

13.3 编辑器的适当规模309

13.3.1 甄别复杂度问题309

13.3.2 折衷无用312

13.3.3 Emacs是个反Unix传统的论据吗314

13.4 软件的适度规模316

PartⅢ319

第14章 语言：C还是非C321

14.1 Unix下语言的丰饶321

14.2 为什么不是C323

14.3 解释型语言和混合策略325

14.4 语言评估325

14.4.1 C326

14.4.2 C++327

14.4.3 Shell330

14.4.4 Perl332

14.4.5 Tcl334

14.4.6 Python336

14.4.7 Java339

14.4.8 EmacsLisp342

14.5 未来趋势344

14.6 选择X工具包346

第15章 工具：开发的战术349

15.1 开发者友好的操作系统349

15.2 编辑器选择350

15.2.1 了解vi351

15.2.2 了解Emacs351

15.2.3 非虔诚的选择：两者兼用352

15.3 专用代码生成器352

15.3.1 yacc和lex353

15.3.2 实例分析：fetchmailrc的语法356

15.3.3 实例分析：Glade356

15.4 make：自动化编译357

15.4.1 make的基本理论357

15.4.2 非C/C++开发中的make359

15.4.3 通用生成目标359

15.4.4 生成Makefile362

15.5 版本控制系统364

15.5.1 为什么需要版本控制364

15.5.2 手工版本控制365

15.5.3 自动化的版本控制366

15.5.4 Unix的版本控制工具367

15.6 运行期调试369

15.7 性能分析370

15.8 使用Emacs整合工具370

15.8.1 Emacs和make371

15.8.2 Emacs和运行期调试371

15.8.3 Emacs和版本控制371

15.8.4 Emacs和Profiling372

15.8.5 像IDE一样，但更强373

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

16.1 猪小兵的故事376

16.2 透明性是重用的关键379

16.3 从重用到开源380

16.4 生命中最美好的就是“开放”381

16.5 何处找384

16.6 使用开源软件的问题385

16.7 许可证问题386

16.7.1 开放源码的资格386

16.7.2 标准开放源码许可证388

16.7.3 何时需要律师390

PartⅣ391

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

17.1 C语言的演化394

17.1.1 早期的C语言395

17.1.2 C语言标准396

17.2 Unix标准398

17.2.1 标准和Unix之战398

17.2.2 庆功宴上的幽灵401

17.2.3 开源世界的Unix标准402

17.3 IETF和RFC标准化过程403

17.4 规格DNA，代码RNA405

17.5 可移植性编程408

17.5.1 可移植性和编程语言选择409

17.5.2 避免系统依赖性412

17.5.3 移植工具413

17.6 国际化413

17.7 可移植性、开放标准以及开放源码414

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

18.1 文档概念418

18.2 Unix风格420

18.2.1 大文档偏爱420

18.2.2 文化风格421

18.3 各种Unix文档格式422

18.3.1 troff和Documenter's Work bench Tools422

18.3.2 TEX424

18.3.3 Texinfo425

18.3.4 POD425

18.3.5 HTML426

18.3.6 DocBook426

18.4 当前的混乱和可能的出路426

18.5 DocBook427

18.5.1 文档类型定义427

18.5.2 其它DTD428

18.5.3 DocBook工具链429

18.5.4 移植工具431

18.5.5 编辑工具432

18.5.6 相关标准和实践433

18.5.7 SGML433

18.5.8 XML—DocBook参考书籍433

18.6 编写Unix文档的最佳实践434

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

19.1 Unix和开放源码438

19.2 与开源开发者协同工作的最佳实践440

19.2.1 良好的修补实践440

19.2.2 良好的项目、档案文件命名实践444

19.2.3 良好的开发实践447

19.2.4 良好的发行制作实践450

19.2.5 良好的交流实践454

19.3 许可证的逻辑：如何挑选456

19.4 为什么应使用某个标准许可证457

19.5 各种开源许可证457

19.5.1 MIT或者Xconsortium许可证457

19.5.2 经典BSD许可证457

19.5.3 Artistic许可证458

19.5.4 通用公共许可证458

19.5.5 Mozilla公共许可证459

第20章 未来：危机与机遇461

20.1 Unix传统中的必然和偶然461

20.2 Plang：未来之路464

20.3 Unix设计中的问题466

20.3.1 Unix文件就是一大袋字节466

20.3.2 Unix对GUI的支持孱弱467

20.3.3 文件删除不可撤销468

20.3.4 Unix假定文件系统是静态的469

20.3.5 作业控制设计拙劣469

20.3.6 UnixAPI没有使用异常470

20.3.7 ioctl（2）和fcntl（2）是个尴尬471

20.3.8 Unix安全模型可能太过原始471

20.3.9 Unix名字种类太多472

20.3.10 文件系统可能有害论472

20.3.11 朝向全局互联网地址空间472

20.4 Unix的环境问题473

20.5 Unix文化中的问题475

20.6 信任的理由477

附录A 缩写词表479

附录B 参考文献483

附录C 贡献者495

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

Colophon510

索引511

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

暂无出版社相关信息，正在全力查找中！

暂无相关书籍摘录，正在全力查找中！

在线阅读地址：UNIX编程艺术在线阅读

在线听书地址：UNIX编程艺术在线收听

在线购买地址：UNIX编程艺术在线购买

模块化代码的首要特质就是封装。封装良好的模块不会过多向外部披露自身的细节，不会直接调用其他模块的实现代码，也不会胡乱共享全局数据。模块之间通过应用程序变成接口（API）——一组严密、定义良好的程序调用和数据结构来通信。这就是模块化原则的内容。

有一种很好的方式来验证API是否设计良好：如果是这用纯人类语言描述设计（不许摘录任何源代码），能否把事情说清楚？养成在编码前为API编写一段非正式书面描述的习惯，是一个非常好的办法。实际上，一些最有能力的开发者，一开始总是定义接口，然后编写解药的注释，对其进行描述，最后才编写代码——因为编写注释的过程就是阐明了代码必须要到的目的。这种描述能够帮助你组织思路，本身就是十分有用的模块说明，而且，最终要可能还想把这些说明做成路标文档，方便以后的人阅读代码。

不要重复自身（Don't Repeat Yourself），意思是说：任何一个知识点在系统内都应当有一个唯一、明确、权威的表述。在本书中，我们更愿意根据Brain Kernighan的建议，把这个远程称为“真理的单点性（Single Point Of Truth）“或者SPOT原则

数据结构也存在类似的SPOT原则：”无垃圾，无混淆（No junk, no confusion）“。”无垃圾“是说数据结构（模型）应该最小化，比如不要让数据结构太通用，居然还能表示不可能存在的情况。”无混淆“是指在真实世界中绝对明确清晰的状态在模型中也应该同样明确清晰。简言之，SPOT原则就是提倡寻找一种数据结构，使得模型中状态跟真实世界系统的状态能够一一对应。

我们将使用五种度量标准对接口风格进行分类：简洁、表现力、易用、透明和脚本化能力。

程序接口的简洁是指一个事务处理需要的动作时间及复杂度有较低的上限（可以用击键量、鼠标手势量和需要多少秒的注意力来衡量）。简洁的接口会以相对较少的比特或状态变化包装更多的作用效果。

接口具有表现力是指接口可以触发相当广泛的行为。最具表现力的接口可以是启动程序设计者没有预见的行为组合，并仍然给予用户有用和一致的结果。

接口易用性同接口要求要求用户记忆的东西成反比——为了使用接口，用户需要特别记忆多少东西（命令，鼠标手势，原语概念）。编程语言的记忆负荷愈高、易用性愈低；菜单和屏幕上标记良好的按钮就较为简单。

接口透明度是用户在使用接口时，几乎没有什么问题、数据或程序的相关状态需要记忆。一个高度透明的接口，对于用户动作的效果，能够自然的给出中间结果、有用反馈和错误通知。所谓的所见即所得（WYSIWYG， what you see is what you get）的接口是图将透明度做到极致，但有时适得其反——尤其是对于定义域视图过度简化时。

相关的可显性概念同样适用于接口设计。一个可显的接口向用户伸出学习援手，比如指向上下文帮助的提示消息，或是一个说明性的弹出式气球。尽可能对于可显性，将要支持的不同接口风格的实现可能大有不同，但是所能够获得的可显程度大部分独立与接口风格。由此，在本章的讨论中，我们并不把可显性作为衡量标准。

同其它美学形式一样，我们需要注意何时设计上的简约已经不再是有价值的自律形式，而开始成为一件伪装的苦行僧外衣——一种实际上把美德作为借口来敷衍工作的纵容方式。

这些富有哲理的原则决不是模糊笼统的泛泛之谈。在Unix世界中，这些原则都是直接源于实践，并形成了具体的规定，我们已经在上文中阐述了一些。以下例举的只是部分内容：

1、只要可行，一切都应该做成与来源和目标无关的顾虑器。

2、数据流应尽可能文本化（这样可以使用标准工具来查看和过滤）。

3、数据库部署和应用协议应该尽可能文本化（让人可以阅读和编辑）。

4、复杂的前端（用户界面）和后端应该泾渭分明。

5、如果可能，用C编写前，先用解释性语言搭建原型。

6、当且仅当只用一门语言编程会提高程序复杂度时，混用语言编程才比单一语言编程来得好。

7、宽收严发（对接收的东西要包容，对输出的东西要严格）。

8、过滤时，不要丢弃的信息决不丢。

9、小就是美，在确保完成任务的基础上，程序功能尽可能少。

要良好的运用Unix哲学，你就应该不断地追求卓越。你必须相信，软件设计是一门技艺，值得你付出所有的智慧、创造力和激情。否则，你的视线就不会超越那些简单、老套的设计和实现；你就会在应该思考的时候急急忙忙跑去编程。你就会在该无情删繁就简的时候反而把问题复杂化——然后你还会反过来奇怪你的代码怎么会那么臃肿、那么难以调试。

书籍介绍

《UNIX编程艺术》主要介绍了Unix系统领域中的设计和开发哲学、思想文化体系、原则与经验，由公认的Unix编程大师、开源运动领袖人物之一Eric S.Raymond倾力多年写作而成。包括Unix设计者在内的多位领域专家也为《UNIX编程艺术》贡献了宝贵的内容。《UNIX编程艺术》内容涉及社群文化、软件开发设计与实现，覆盖面广、内容深邃，完全展现了作者极其深厚的经验积累和领域智慧。