Unix编程艺术 pdf 中文版

《UNIX编程艺术》写作了五年之久，作者将U NIX三十年中未见纸端的艰难胜利的软件工程智慧融入文字，使UNIX家族成为最好最其创新软件的哲学、设汁模式、工具、文化和传统，Raymond将之第一次带给我们．并向我们展示它们如何影响着当今的Linux和开源运动。通过大量来自顶尖项目的实例，你将学会如何运用这些智慧经验来建造更优雅、更可移植、更加好用和更加长久的软件。本书主要介绍了Unix系统领域中的设计和开发哲学、思想文化体系、原则与经验，由公认的Unix编程大师、开源运动领袖人物之一Eric S. Raymond倾力多年写作而成。包括Unix设计者在内的多位领域专家也为本书贡献了宝贵的内容。本书内容涉及社群文化、软件开发设计与实现，覆盖面广、内容深邃，完全展现了作者极其深厚的经验积累和领域智慧。作者简介　　Eric S．Raymond，从1982年开始就是UNIX开发者。作为开源社区文化的倡导和呼吁者，他在《大教堂与市集》中写下了这场运动的宣言，同时他还是《新黑洞词典》的编辑。目录Contents序 xxvPart 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－19952.1.1 创世纪：1969－19712.1.2 出埃及记：1971－19802.1.3 TCP/IP 和Unix内战：1980－19902.1.4 反击帝国：1991－19952.2 黑客的起源和历史：1961－19952.2.1 游戏在校园的林间：1961－19802.2.2 互联网大融合与自由软件运动：1981－19912.2.3 Linux 和实用主义者的应对：1991－19982.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 VMS3.2.2 MacOS3.2.3 OS/23.2.4 Windows NT3.2.5 BeOS3.2.6 MVS3.2.7 VM/CMS3.2.8 Linux3.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 XML5.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 作为通用应用协议的HTTP5.4.3 BEEP：块可扩展交换协议5.4.4 XML-RPC，SOAP和Jabber第6章 透明性：来点儿光6.1 研究实例6.1.1 实例分析：audacity6.1.2 实例分析：fetchmail的-v选项6.1.3 实例分析：GCC6.1.4 实例分析：kmail6.1.5 实例分析：SNG6.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 案例分析：sng8.2.2 案例分析：正则表达式8.2.3 案例分析：Glade8.2.4 案例分析：m8.2.5 案例分析：XSLT8.2.6 案例分析：The Documenter＇s Workbench Tools8.2.7 案例分析：fetchmail的运行控制语法8.2.8 案例分析：awk8.2.9 案例分析：PostScript8.2.10 案例分析：bc和dc8.2.11 案例分析：Emacs Lisp8.2.12 案例分析：JavaScript8.3 设计微型语言8.3.1 选择正确的复杂度8.3.2 扩展和嵌入语言8.3.3 编写自定义语法8.3.4 宏-慎用8.3.5 语言还是应用协议第9章 生成：提升规格说明的层次9.1 数据驱动编程9.1.1 实例分析：ascii9.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 实例分析：fetchmail10.6.2 实例分析：XFree86服务器10.7 论打破规则第11章 接口：Unix环境下的用户接口设计模式11.1 最小立异原则的应用11.2 Unix接口设计的历史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 编译器模式11.6.6 ed模式11.6.7 Roguelike 模式11.6.8 “引擎和接口分离”模式11.6.9 CLI服务器模式11.6.10 基于语言的接口模式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章 复杂度：尽可能简单，但别简过了头13.1 谈谈复杂度13.1.1 复杂度的三个来源13.1.2 接口复杂度和实现复杂度的折中13.1.3 必然的、可能的和偶然的复杂度13.1.4 映射复杂度13.1.5 当简洁性不能胜任13.2 五个编辑器的故事13.2.1 ed13.2.2 vi13.2.3 Sam13.2.4 Emacs13.2.5 Wily13.3 编辑器的适当规模13.3.1 甄别复杂度问题13.3.2 折衷无用13.3.3 Emacs是个反Unix传统的论据吗13.4 软件的适度规模Part III第14章 语言：C还是非C14.1 Unix下语言的丰饶14.2 为什么不是C14.3 解释型语言和混合策略14.4 语言评估14.4.1 C14.4.2 C++14.4.3 Shell14.4.4 Perl14.4.5 Tcl14.4.6 Python14.4.7 Java14.4.8 Emacs Lisp14.5 未来趋势14.6 选择X工具包第15章 工具：开发的战术15.1 开发者友好的操作系统15.2 编辑器选择15.2.1 了解vi15.2.2 了解Emacs15.2.3 非虔诚的选择：两者兼用15.3 专用代码生成器15.3.1 yacc和lex15.3.2 实例分析：fetchmailrc的语法15.3.3 实例分析：Glade15.4 make：自动化编译15.4.1 make的基本理论15.4.2 非C/C++开发中的make15.4.3 通用生成目标15.4.4 生成Makefile15.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和make15.8.2 Emacs和运行期调试15.8.3 Emacs和版本控制15.8.4 Emacs和Profiling15.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 何时需要律师Part IV第17章 可移植性：软件可移植性与遵循标准17.1 C语言的演化17.1.1 早期的C语言17.1.2 C 语言标准17.2 Unix 标准17.2.1 标准和Unix之战17.2.2 庆功宴上的幽灵17.2.3 开源世界的Unix标准17.3 IETF和RFC标准化过程17.4 规格DNA，代码RNA17.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 Tools18.3.2 TEX18.3.3 Texinfo18.3.4 POD18.3.5 HTML18.3.6 DocBook18.4 当前的混乱和可能的出路18.5 DocBook18.5.1 文档类型定义18.5.2 其它DTD18.5.3 DocBook 工具链18.5.4 移植工具18.5.5 编辑工具18.5.6 相关标准和实践18.5.7 SGML18.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名字种类太多20.3.10 文件系统可能有害论20.3.11 朝向全局互联网地址空间20.4 Unix的环境问题20.5 Unix文化中的问题20.6 信任的理由附录A 缩写词表附录B 参考文献附录C 贡献者附录D 无根的根：无名师的Unix心传Colophon