Shell 指令碼程式設計陷阱 | Linux 中國

隨著程式碼量的增加，你的指令碼會變得越來越難以維護，但你也不會想用別的語言重寫一遍，因為你已經在這個 shell 版上花費了很多時間。

— Martin Tournoij

 

Shell 指令碼很棒，你可以非常輕鬆地寫出有用的東西來。甚至像是下麵這個傻瓜式的命令：

1. # 用含有 Go 的詞彙起名字：
2. $ grep -i ^go /usr/share/dict/* | cut -d: -f2 | sort -R | head -n1
3. goldfish

如果用其他程式語言，就需要花費更多的腦力，用多行程式碼實現，比如用 Ruby 的話：

1. puts(Dir['/usr/share/dict/*-english'].map do |f|
2. File.open(f)
3. .readlines
4. .select { |l| l[0..1].downcase == 'go' }
5. end.flatten.sample.chomp)

Ruby 版本的程式碼雖然不是那麼長，也並不複雜。但是 shell 版是如此簡單，我甚至不用實際測試就可以確保它是正確的。而 Ruby 版的我就沒法確定它不會出錯了，必須得測試一下。而且它要長一倍，看起來也更複雜。

這就是人們使用 Shell 指令碼的原因，它簡單卻實用。下麵是另一個例子：

1. 1. curl https://nl.wikipedia.org/wiki/Lijst_van_Nederlandse_gemeenten |
   2. grep '^
   3. |
   5. sed -r " s=""/>(.+).*

|\1|’ |

• grep -Ev '(^Tabel van|^Lijst van|Nederland)'

這個指令碼可以從維基百科上獲取荷蘭基層政權的串列。幾年前我寫了這個臨時的指令碼，用來快速生成一個資料庫，到現在它仍然可以正常執行，當時寫它並沒有花費我多少精力。但要用 Ruby 完成同樣的功能則會麻煩得多。

---

現在來說說 shell 的缺點吧。隨著程式碼量的增加，你的指令碼會變得越來越難以維護，但你也不會想用別的語言重寫一遍，因為你已經在這個 shell 版上花費了很多時間。

我把這種情況稱為“Shell 指令碼程式設計陷阱”，這是沉沒成本謬論[1]的一種特例（LCTT 譯註：“沉沒成本謬論”是一個經濟學概念，可以簡單理解為，對已經投入的成本可能被浪費而念念不忘）。

實際上許多指令碼會增長到超出預期的大小，你經常會花費過多的時間來“修複某個 bug”，或者“新增一個小功能”。如此迴圈往複，讓人頭大。

如果你從一開始就使用 Python、Ruby 或是其他類似的語言來寫這個程式，你可能會在寫第一版的時候多花些時間，但以後維護起來就容易很多，bug 也肯定會少很多。

以我的 packman.vim[2] 指令碼為例。它起初只包含一個簡單的用來遍歷所有目錄的 for 迴圈，外加一個 git pull，但在這之後就剎不住車了，它現在有 200 行左右的程式碼，這肯定不能算是最複雜的指令碼，但假如我一上來就按計劃用 Go 來編寫它的話，那麼增加一些像“列印狀態”或者“從配置檔案裡克隆新的 git 庫”這樣的功能就會輕鬆很多；新增“並行克隆”的支援也幾乎不算個事兒了，而在 shell 腳本里卻很難實現（儘管不是不可能）。事後看來，我本可以節省時間，並且獲得更好的結果。

出於類似的原因，我很後悔寫出了許多這樣的 shell 指令碼，而我在 2018 年的新年誓言就是不要再犯類似的錯誤了。

附錄：問題彙總

需要指出的是，shell 程式設計的確存在一些實際的限制。下麵是一些例子：

◈ 在處理一些包含“空格”或者其他“特殊”字元的檔案名時，需要特別註意細節。絕大多數指令碼都會犯錯，即使是那些經驗豐富的作者（比如我）編寫的指令碼，因為太容易寫錯了，只新增引號是不夠的[3]。

◈ 有許多所謂“正確”和“錯誤”的做法。你應該用 which 還是 command？該用 $@ 還是 $*，是不是得加引號？你是該用 cmd $arg 還是 cmd “$arg”？等等等等。

◈ 你沒法在變數裡儲存空位元組（0x00）；shell 指令碼處理二進位制資料很麻煩。

◈ 雖然你可以非常快速地寫出有用的東西，但實現更複雜的演演算法則要痛苦許多，即使用 ksh/zsh/bash 擴充套件也是如此。我上面那個解析 HTML 的指令碼臨時用用是可以的，但你真的不會想在生產環境中使用這種指令碼。

◈ 很難寫出跨平臺的通用型 shell 指令碼。/bin/sh 可能是 dash 或者 bash，不同的 shell 有不同的執行方式。外部工具如 grep、sed 等，不一定能支援同樣的引數。你能確定你的指令碼可以適用於 Linux、macOS 和 Windows 的所有版本嗎（無論是過去、現在還是將來）？

◈ 除錯 shell 指令碼會很難，特別是你眼中的語法可能會很快變得記不清了，並不是所有人都熟悉 shell 程式設計的語境。

◈ 處理錯誤會很棘手（檢查 $? 或是 set -e），排查一些超過“出了個小錯”級別的複雜錯誤幾乎是不可能的。

◈ 除非你使用了 set -u，變數未定義將不會報錯，而這會導致一些“搞笑事件”，比如 rm -r ~/$undefined 會刪除使用者的整個家目錄（瞅瞅 Github 上的這個悲劇[4]）。

◈ 所有東西都是字串。一些 shell 引入了陣列，能用，但是語法非常醜陋和費解。帶分數的數字運算仍然難以應付，並且依賴像 bc 或 dc 這樣的外部工具（$(( .. )) 這種方式只能對付一下整數）。

反饋

你可以發郵件到 martin@arp242.net[5]，或者在 GitHub 上建立 issue[6] 來向我反饋，提問等。