傳世經典書叢：UNIX編程藝術

《傳世經典書叢：UNIX編程藝術》是2012年電子工業出版社出版的圖書，作者是埃瑞克·S.理曼德(Eric S. Raymond)。

基本介紹

• 中文名：傳世經典書叢:UNIX編程藝術
• 作者：埃瑞克•S.理曼德
• 譯者：姜宏
• 出版社：電子工業出版社 
• 出版時間：2012年8月1日
• 頁數：530 頁
• 定價：99.00
• 開本：16 開
• ISBN：9787121176654, 7121176653
• 外文名：The Art of UNIX Programming
• 類型：計算機與網際網路
• 語種：簡體中文

圖書目錄

序

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

內容簡介

《UNIX編程藝術》分為四部分：場景、設計、工具和社群。第一部分(場景)涉及哲學和歷史，為後續內容埋下伏筆。第二部分(設計)將Unix哲學的原理細分為有關設計與實現的、更專門的建議。第三部分(工具)著眼於Unix所提供的工具，可助你解決問題。第四部分(社群)則講述人與人之間的事務與約定，而這正是Unix文化擁有高效能的原因。

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

作者簡介

作者:(美)Raymond

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

內容簡介

《UNIX編程藝術》分為四部分：場景、設計、工具和社群。第一部分(場景)涉及哲學和歷史，為後續內容埋下伏筆。第二部分(設計)將Unix哲學的原理細分為有關設計與實現的、更專門的建議。第三部分(工具)著眼於Unix所提供的工具，可助你解決問題。第四部分(社群)則講述人與人之間的事務與約定，而這正是Unix文化擁有高效能的原因。

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

作者簡介

作者:(美)Raymond