用C語言編寫Linux實用程序的藝術

Linux 和其他類 UNIX 系統總是附帶了大量的工具，它們執行從顯而易見的到不可思議的廣泛功能。類 UNIX 編程環境的成功很大程度上歸功於工具的高品質和選擇，以及這些工具之間相互銜接的簡易性。 作為 開發 人員，您可能會發現現有實用程序並不總是能夠解決問
　　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 的更多信息。
　　
　　如果您即將開始編寫一個實用程序，請花一點時間浏覽一下各種系統，以確定那樣的實用程序是否已經存在。不要害怕在 BSD 上借用 Linux 實用程序，或在 Linux 上借用 BSD 實用程序；實用程序代碼的樂趣之一在於，幾乎所有實用程序都具有很好的可移植性。
　　
　　不要忘了考察一下組合現有應用程序來形成一個實用程序的可能性。從理論上講，組合現有程序來形成的實用程序運行得不足夠快是可能的，但是編寫一個新的實用程序很少會比等待一個稍慢的管道更快。
　　
　　一個例子實用程序
　　從某種意義上，這個程序是一個可執行文件，因為對於作為過濾器來說，它決不會有任何用處。然而，它作為一個命令行實用程序卻工作得非常好。
　　
　　這個程序僅做一件事情。它以近乎完美的輸出格式輸出 /usr/include/sys/errno.h 中的 errno 行。例如：
　　
　　$ errno 22
　　EINVAL [22]: Invalid argument
　　
　　清單 2. errno 查找器
　　
　　　　#!/bin/sh
　　　　usage() {
　　　　　　echo >&2 'usage: errno [numbers or error names]\n'
　　　　　　exit 1
　　　　}
　　　　for i
　　　　do
　　　　　　case '$i' in
　　　　　　[0-9]*)
　　　　　　　　awk '/^#define/ && $3 == '$i' {
　　　　　　　　　　for (i = 5; i < NF; ++i) {
　　　　　　　　　　　　foo = foo ' ' $i;
　　　　　　　　　　}
　　　　　　　　　　printf('%-22s%s\n', $2 ' [' $3 ']:', foo);
　　　　　　　　　　foo = '
　　　　　　　　}' < /usr/include/sys/errno.h
　　　　　　　　;;
　　　　　　E*)
　　　　　　　　awk '/^#define/ && $2 == ''$i'' {
　　　　　　　　　　for (i = 5; i < NF; ++i) {
　　　　　　　　　　　　foo = foo ' ' $i;
　　　　　　　　　　}
　　　　　　　　　　printf('%-22s%s\n', $2 ' [' $3 ']:', foo);
　　　　　　　　　　foo = '
　　　　　　　　}' < /usr/include/sys/errno.h
　　　　　　　　;;
　　　　　　*)
　　 echo >&2 'errno: can't figure out whether '$i' is a name or a number.'
　　　　　　　　usage
　　　　　　　　;;
　　　　　　esac
　　　　done
　　
　　這個程序通用化了嗎？是的，非常理想。它同時支持數字和符號名稱。另一方面，它不知道關於可能具有相同格式的其他文件的信息，比如 /usr/include/sys/signal.h。可以容易地擴展它來做到這點，但是對於這樣一個便利的實用能夠程序，簡單地創建一個名為“signal”的拷貝來讀取 signal.h，同時使用“SIG*”作為模式來匹配名稱，這樣會更容易。
　　
　　雖然這僅比對系統頭文件使用 grep 方便一小點，但是它更不容易出錯。它不會因為考慮不周的參數而產生無用的結果。另一方面，如果沒有從頭文件中找到給定的名稱或數字，它不會產生診斷信息。它也不會費心去糾正某些輸入錯誤。而且，由於命令行實用程序從來沒有打算在自動化的環境中使用，因此它的上述特性無可非議。
　　
　　另一個例子可能是取消對輸入排序的程序（請參閱 參考資料 以獲得指向此實用程序的鏈接）。這相當簡單；也就是讀入輸入文件，以某種方式存儲它們，然後生成一個隨機順序來輸出那些行。這是一個幾乎具有無限應用前景的實用程序。編寫這個實用程序也比編寫排序程序容易得多；例如，您不需要指定您沒有對哪些鍵排序，或者是您希望按字母順序、詞法順序還是按數字順序隨機排序。棘手的部分在於讀入可能非常長的行。事實上，上面提供的版本在搞欺騙；它假設所讀入的行中沒有空字節。糾正這個問題要困難多了，我在編寫它時懶得去理會它。
　　
　　結束語
　　如果您發現自己在重復執行某個任務，可以考慮編寫一個程序來完成這個任務。如果事實證明該程序更通用化一點是合理的，那就通用化它，這樣您就編寫了一個實用程序。
　　
　　不要在您第一次需要某個實用程序的時候設計它。要等到您具有一些經驗之後才著手設計。請隨意地編寫一兩個原型；優秀的實用程序比糟糕的實用程序更能證明所花的時間和研究工作的價值。如果原先設想的出色實用程序最終卻在您編寫它之後成為無用之物，不要感到遺憾。如果您發現自己對新程序的缺點感到沮喪，您只需再執行另外一個原型化階段。如果結果證明它是無用的，不奇怪，有時會發生這樣的事情。
　　
　　您要尋求的是這樣一個程序，它查找您的最初使用模式之外的通用應用。我編寫 unsort 是因為，我希望找到一種從舊的 X11“rgb.txt”文件中獲得隨機顏色序列的容易途徑。從那以後，我將它用於令人難以置信的大量任務中，這些任務都不是為了生成用於調試和基准排序例程的測試數據。
　　
　　優秀的實用程序能夠為您在所有不很理想的作品上所花的時間帶來回報。要做的下一件事情是使它對其他人可用，以便他們能夠試驗它。也要使您失敗的嘗試對其他人可用，也許其他人對某個實用程序具有您所不需要的用途。更重要的是，您的失敗的實用程序也許是其他某個人的原型，從而給每個人帶來一個美妙的實用程序。