歡迎光臨
每天分享高質量文章

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. curl https://nl.wikipedia.org/wiki/Lijst_van_Nederlandse_gemeenten |
    2. grep '^
    3. |
    4. 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?該用 [email protected] 還是 $*,是不是得加引號?你是該用 cmd $arg 還是 cmd “$arg”?等等等等。
◈ 你沒法在變數里儲存空位元組(0x00);shell 腳本處理二進制資料很麻煩。
◈ 雖然你可以非常快速地寫出有用的東西,但實現更複雜的演算法則要痛苦許多,即使用 ksh/zsh/bash 擴展也是如此。我上面那個解析 HTML 的腳本臨時用用是可以的,但你真的不會想在生產環境中使用這種腳本。
◈ 很難寫出跨平臺的通用型 shell 腳本。/bin/sh 可能是 dash 或者 bash,不同的 shell 有不同的運行方式。外部工具如 grepsed 等,不一定能支持同樣的引數。你能確定你的腳本可以適用於 Linux、macOS 和 Windows 的所有版本嗎(無論是過去、現在還是將來)?
◈ 除錯 shell 腳本會很難,特別是你眼中的語法可能會很快變得記不清了,並不是所有人都熟悉 shell 編程的語境。
◈ 處理錯誤會很棘手(檢查 $? 或是 set -e),排查一些超過“出了個小錯”級別的複雜錯誤幾乎是不可能的。
◈ 除非你使用了 set -u,變數未定義將不會報錯,而這會導致一些“搞笑事件”,比如 rm -r ~/$undefined 會刪除用戶的整個家目錄(瞅瞅 Github 上的這個悲劇[4])。
◈ 所有東西都是字串。一些 shell 引入了陣列,能用,但是語法非常醜陋和費解。帶分數的數字運算仍然難以應付,並且依賴像 bc 或 dc 這樣的外部工具($(( .. )) 這種方式只能對付一下整數)。

反饋

你可以發郵件到 [email protected][5],或者在 GitHub 上創建 issue[6] 來向我反饋,提問等。

已同步到看一看
赞(0)

分享創造快樂