UNIX編程藝術（簡體書）

《傳世經典書叢：UNIX編程藝術》主要介紹了Unix系統領域中的設計和開發哲學、思想文化體系、原則與經驗，由公認的Unix編程大師、開源運動領袖人物之一Eric S.Raymond傾力多年寫作而成。包括Unix設計者在內的多位領域專家也為本書貢獻了寶貴的內容。本書內容涉及社群文化、軟件開發設計與實現，覆蓋面廣、內容深邃，完全展現了作者極其深厚的經驗積累和領域智慧。．

Eric S.RAYMOND 從1982年開始就是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

terminfo本身使用文件系統作為一個簡單的層級數據庫。這種偷懶相當具有建設性，符合經濟性原則和透明性原則。這意味著對文件系統進行瀏覽、檢查和修改的所有普通工具都可以用于對terminfo數據庫進行瀏覽、檢查和修改；無需編寫和調試專用工具（用于打包和解包單個記錄的tic（1）和infocmp（1）工具除外）。這也意味著要加速數據庫的訪問就得要加速文件系統本身，知道這一點可以使更多應用程序受益，而不僅僅是curses（3）的用戶。
這種結構還有另外一種優點，但在terminfo例子中沒有展示出來：你開始使用Unix的授權機制而不用自己編寫帶來額外bu9的訪問控制層。這也是采納而不是對抗Unix“一切皆文件”基本原則的結果。
terminfo目錄的布局在大多數Unix文件系統上都很浪費空間。每條目長度通常在400～1400字節之間，但是文件系統通常為每一個非空磁盤文件至少分配4k的空間。出于選擇壓縮二進制格式的同一個原因，即為了把terminfo使用的程序的啟動延時降到最小，設計者接受了這個代價。同一價格所能買到的磁盤容量已經猛增了一千倍，更能證明這個決定的正確。
比較這種格式和Microcsoft Windows的注冊表文件所用的格式很有啟發意義。注冊表是Windows本身及應用程序都使用的屬性數據庫。所有注冊記錄都存放在一個大文件中。注冊記錄既包含文本也包含二進制數據，需要專用的編輯工具。別的不說，這種“一個大文件”的方法還導致了臭名昭著的“注冊表蠕變”現象；平均訪問時間隨著新記錄的加入而無限上升。因為系統沒有提供標準APl來編輯注冊表，應用程序本身使用專用代碼編輯注冊表，使得注冊表極易受損，甚至能夠鎖定整個系統。
使用Unix文件系統作為數據庫是一種策略，對數據庫要求簡單的其它應用程序可以效仿并從中受益。不這樣做的充分理由通常與性能問題無關，更可能的情形是數據庫關鍵字不太適合做文件名。無論如何，這是在原型設計時非常有用的一種很好的快速編程方法。
6.1.7 實例分析：Freeciv數據文件
Freeciv是一款受到Sid Meier經典的Civilization H啟發而制作的開源策略游戲。在該游戲中，每個玩家從一群到處流浪的新石器游牧民開始締造一個文明。玩家的文明可以探索并拓殖世界，參與戰爭，從事貿易和研究先進技術。有些玩家實際上可能是人工智能；和這些電腦玩家玩單機游戲很有挑戰性。如果誰統治了整個世界，或者第一個研制出先進技術從而獲得宇宙飛船飛往半人馬座阿爾法星（Alpha Centauri），誰就是游戲的勝利者。源碼和文檔可以在處獲得。