編寫Linux實用程序的藝術

class="22757">

　　Linux 和其他類 UNIX 系統總是附帶了大量的工具，它們執行從顯而易見的到不可思議的廣泛功能。類 UNIX 編程環境的成功很大程度上歸功於工具的高品質和選擇，以及這些工具之間相互銜接的簡易性。

　　作為開發人員，您可能會發現現有實用程序並不總是能夠解決問題。雖然能夠通過結合使用現有實用程序來容易地解決許多問題，然而解決其他問題卻至少需要一些實 際的編程工作。這些後面的任務通常是創建新實用程序的候選任務，結合現有實用程序來創建新實用程序可以通過做最少的工作來解決問題。本文考察優秀實用程序所具有的品質，以及設計這種實用程序所經歷的過程。

　　優秀的實用程序具有哪些品質？

　　Kernighan & Pike 所著的 The UNIX Programming Environment 一書中包含了對此問題的精彩討論。優秀的實用程序是把自己的工作做得盡可能好的實用程序。它必須與其他實用程序配合融洽；必須能夠容易地與其他實用程序結合使用。無法與其他實用程序結合使用的程序不是實用程序，而是應用程序。

　　實用程序應該允許您根據手邊的材料廉價而容易地構建一次性的應用程序。許多人認為實用程序就像是工具箱中的工具。設計實用程序的目標不是為了讓單個工具來做所有事情，而是為了擁有一組工具，其中每個工具都盡可能好地做一件事情。

　　有些實用程序自身就是相當有用的，而其他實用程序則必須與一系列實用程序配合使用。前者的例子包括 sort 和 grep。另一方面，xargs 除了與其他實用程序（最常見的是 find）配合使用外，很少單獨使用。

　　使用什麼語言來編寫實用程序？

　　大多數 UNIX 系統實用程序都是用 C 語言來編寫的。本文中的例子使用 Perl 和 sh。應該使用恰當的工具來做恰當的事情。如果您對某個實用程序使用得足夠頻繁，那麼用編譯型語言來編寫它的成本也許能通過性能提升來獲得回報。另一方面，對於程序的工作負荷很輕這種相當普遍的情況，使用腳本語言也許會提供更快的開發速度。

　　如果無法肯定，您應該使用自己最了解的語言。至少當您在對某個實用程序進行原型化，或在弄清它是如何有用時，程序員效率將優先於性能調整。大多數 UNIX 系統實用程序都是用 C 編寫的，這只是因為這些實用程序使用得足夠頻繁，以致考慮效率比考慮開發成本更加重要。Perl 和 sh（或 ksh）可能是用於快速原型化的很好語言。對於與其他程序配合實用的實用程序，使用 shell 來編寫它們或許要比使用更傳統的編程語言來編寫它們要容易一些。另一方面，當您希望與原始的字節交互時，C 或許就是最好的選擇。

　　設計實用程序
　　一個不錯的經驗法則就是當您第二次必須解決某個問題時，首先考慮實用程序的設計。不要對第一次編寫的一次性作品感到遺憾；您可以將它看作是一個原型。第二次，請把您所需的功能與第一次所需的功能作比較。在第三次前後，您應該開始考慮花時間來編寫一個通用實用程序。即使純粹的重復性任務也可能會給實用程序的開發帶來好處；例如，由於人們對嘗試以通用的方式重命名文件感到失望，於是開發了許多通用文件重命名程序。

　　下面是一些實用程序設計目標；每個目標將在下面單獨的小節中介紹。

做好一件事情。 　　
成為一個過濾器。 　　
通用化。　　
健壯。 　　
新穎。
　　做好一件事情

　　做好一件事情；不要糟糕地做多件事情。關於做好一件事情的最佳例子或許是 sort。除了 sort 外，沒有其他 哪個實用程序具有排序功能。基本的思想很簡單：如果一次僅解決一個問題，您就能花時間把它解決好。

　　設想一下，如果大多數程序都具有排序功能，但是有些僅支持按詞法排序，而其他一些僅支持按數字排序，另外一些甚至支持關鍵字選擇而不是對整行排序，那將是一件多麼令人沮喪的事情。起碼，這也是惱人的。

　　當您發現某個問題需要解決時，應嘗試將問題分解為多個部分，不要重復那些其他實用程序中已經存在的部分。您對允許配合現有工具使用的工具關注得越多，您的實用程序就越有可能保持有用。

　　也許您需要編寫多個程序。完成專門任務的最佳途徑通常是編寫一兩個實用程序，再用一些線索將它們聯系起來，而不是編寫單個程序來解決整件事情。使用 20 行的 shell 腳本來將新的實用程序與現有工具結合起來是很理想的。如果嘗試一次解決整個問題，隨之而來的第一個變更就可能要求您全盤重新考慮。

　　我偶爾需要從數據庫生成兩列或三列的輸出。編寫一個程序在單個列中生成輸出，然後結合使用一個對輸出進行分列的程序，這樣通常會更有效率。組合這兩個實用程序的 shell 腳本本身是臨時性的，單獨的實用程序比這個腳本的使用壽命更長。

　　有些實用程序服務於非常專一的需要。針對一個包含大量內容的目錄，如果 ls 的輸出非常快地滾出屏幕，這可能是因為其中有一個文件具有非常長的文件名，從而迫使 ls 僅對輸出使用單個列。使用 more 來對輸出分頁會花一些時間。為什麼不像下面這樣就按長度對行排序，然後通過 tail 來管道輸出結果呢？

　　清單 1. 世間能找到的最小實用程序 sl

#/usr/bin/perl -w
print sort { length $a <=> length $b } <>;

　　清單 1 中的腳本確切地就做一件事情。它不接受任何選項，因為它不需要選項；它僅關心行的長度。歸功於 Perl 便利的 <> 表達方式，這個小實用程序既適用於標准輸入，也適用於命令行指定的文件。

　　成為一個過濾器
　　幾乎所有實用程序都最適合想像為過濾器，盡管有一些非常有用的實用程序不符合這個模型。（例如，某個程序在執行計數時可能非常有用，盡管它作為過濾器工作得並不好。僅接受命令行參數作為輸入並潛在地產生復雜輸出的程序可能非常有用。）然而，大多數實用程序都應該作為過濾器來工作。根據慣例，過濾器對文本的行起作用。大多數過濾器都應該支持多個輸入文件。

　　記住實用程序需要在命令行和腳本中運行。有時，理想的行為會稍有不同。例如，大多數版本的 ls 都會在向終端寫出時自動將輸入排序到多個列中。grep 的默認行為是在指定多個文件的情況下打印從其中找到匹配項的那個文件名稱。這樣的差別應該與用戶希望的實用程序工作方式有關，而不是與其他事項有關。例如，舊版本的 GNU bc 在啟動時顯示強迫性的版權標記。請不要那樣做。讓您的實用程序僅做它應該做的事情。

　　實用程序喜歡生活在管道中。管道允許實用程序專注於自己的工作，而不是去關注旁枝末節。為了生活在管道中，實用程序需要從標准輸入讀取數據，然後向標准輸出寫出數據。如果您希望處理記錄，那麼您最好能夠使每一行成為一個“記錄”。諸如 sort 和 join 之類的現有程序已經在那樣考慮了。它們將會因為您這樣做而感謝您。

　　我偶爾使用這樣一個實用程序，它針對一個文件樹反復調用其他程序。這充分利用了標准的 UNIX 實用程序過濾器模型，但是該模型僅適用於讀取輸入然後寫出輸出的實用程序；不能將它用於就地操作或接受輸入輸出文件名的實用程序。

　　可以使用標准輸入來運行的大多數程序也完全可以針對單個文件或一組文件運行。注意，可以證明這樣違背了反對重復工作的規則；顯而易見，這可以通過將 cat 的輸出饋送給該系列中的下一個程序來解決。然而這在實踐中似乎是合理的。

　　有些程序可能合法地讀取一種格式的記錄，但是卻產生完全不同的輸出。這樣的一個例子就是將輸入材料劃分為列的實用程序。這樣一個實用程序可能將輸入中的行視為記錄，但是卻在輸出中的每行上產生多個記錄。

　　並非每個實用程序都完全符合這個模型。例如，xargs 不是接受記錄而是接受文件名作為輸入，並且所有的實際處理都是由其他程序完成的。

　　通用化

　　嘗試將任務看作與您實際執行的任務類似；如果您能找出這些任務的通用描述，那麼最好嘗試編寫一個符合該描述的實用程序。例如，如果您發現自己一天在根據詞法對文本排序，而另一天在根據數字對文本排序，那麼考慮編寫一個通用排序實用程序也許是有意義的。

　　對功能進行通用化有時會導致您發現：某個看起來似乎像單個實用程序的程序，實際上卻是配合起來使用的兩個實用程序。這很好。編寫兩個設計良好的實用程序可能要比編寫一個丑陋的或復雜的實用程序更容易。

　　做好一件事情並不意味著 僅僅 做一件事情。它意味著處理一致但有用的問題空間。許多人都使用 grep。然而，它的大量效用在於執行相關任務的能力。grep 的各種選項完成許多小實用程序的工作，如果這些工作都由單獨的小實用程序來完成，最終會造成大量共享的、重復的代碼。

　　這條規則，以及做好一件事情的規則，都是一個根本原理的必然結果：無論何時都要盡可能避免代碼重復。如果您編寫半打程序，其中每個都對行排序，您最終可能必須六次修復六個類似的 bug，而不是去使用一個得到更好維護的 sort 程序。

　　這是編寫實用程序的一部分，即把大多數工作添加到完成該實用程序的過程中。您也許沒有時間在最初就完全通用化一個實用程序，但是當您一直使用該實用程序就會獲得相應的回報。

　　有時，向某個程序添加相關功能是很有用的，即使這個功能並不是用來完成完全相同的任務。例如，當運行在終端設備上時，對原始二進制數據進行完美打印的程序可能更為有用，因為它使終端進入原始模式。這樣使得測試涉及鍵盤映射、新鍵盤等的問題變得容易多了。不確定為什麼當您按 delete 鍵時卻得到代字號（~）嗎？ 這是弄清實際發送了什麼內容的容易途徑。這並不是完全相同的任務，但它足夠類似，因而可能成為一個附加特性。

　　清單 2 中的 errno 實用程序就是通用化