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 實用程序就是通用化的很好例子，因為它同時支持數字和符號名稱。
　　健壯
　　實用程序的穩定性是很重要的。容易崩潰或無法處理真實數據的實用程序不是有用的實用程序。實用程序應該能夠處理任意長度的行、巨型文件，等等。實用程序無法處理超過其內存容量的數據集或許是可以容忍的，但是有些實用程序不是這樣；例如， sort 通過使用臨時文件，一般能夠對比其內存容量大得多的數據集排序。
　　應該盡量確保弄清楚您的實用程序可能要操作哪些數據。不要簡單地忽略無法處理的數據的可能性。應該檢查這種情況并診斷您的實用程序。錯誤消息越明確，您對用戶就越有幫助。盡量給用戶提供足夠的信息，以便讓他們知道發生了什么情況以及如何解決。當處理數據文件時，盡量準確識別出不良的數據。當嘗試解析數字時，不要簡單地放棄；應該告訴用戶您得到了什么數據，而且如果可能的話，還應該告訴用戶該數據位于輸入流中的哪一行上。
　　作為一個很好的例子，請考慮 dc 的兩種實現之間的區別。如果您運行 dc /home ，其中一種實現會顯示“Cannot use directory as input！”而另一種實現只是無聲地返回，沒有錯誤消息，也沒有不尋常的退出代碼。當您錯誤地鍵入一個 cd 命令時，您更希望當前路徑中有哪一種實現呢？類似地，如果您提供某個目錄中的數據流（或許是執行 dc 《 /home ），前者會給出詳細的錯誤消息。另一方面，當它在獲得無效數據的早期就選擇放棄可能是理想的。
　　安全漏洞經常植根于在意料之外的數據面前表現得不夠健壯的程序中。務必記住，優秀的實用程序能夠設法在 shell 腳本中作為根（root）用戶身份運行。諸如 find 這樣的程序中的緩沖區溢出可能會給大量的系統帶來風險。
　　程序對意料之外的數據處理得越好，它就更可能適應變化的環境。通常，設法使程序更健壯會導致您更好地理解該程序的作用，從而更好地使之通用化。
　　新穎
　　要編寫的最糟糕的實用程序種類之一就是您已經有了的實用程序。我編寫過一個名為 count 的美妙的實用程序。它允許我執行幾乎任何計數任務。它是一個出色的實用程序，但是已經有一個名為 jot 的標準 BSD 實用程序做同樣的事情。同樣地，我的一個用于將數據轉換為列的靈活的程序重復了一個現有實用程序 rs 的功能，這個實用程序同樣可以在 BSD 系統上找到，只不過 rs 更靈活，設計得更好。請參閱下面的 參考資料 以了解關于 jot 和 rs 的更多信息。