Shell 指令碼很棒，你可以非常輕鬆地寫出有用的東西來。甚至像是下面這個傻瓜式的命令：
# 用含有 Go 的詞彙起名字：$ grep -i ^go /usr/share/dict/* | cut -d: -f2 | sort -R | head -n1goldfish如果用其他程式語言，就需要花費更多的腦力，用多行程式碼實現，比如用 Ruby 的話：
puts(Dir['/usr/share/dict/*-english'].map do |f| File.open(f) .readlines .select { |l| l[0..1].downcase == 'go' }end.flatten.sample.chomp)Ruby 版本的程式碼雖然不是那麼長，也並不複雜。但是 shell 版是如此簡單，我甚至不用實際測試就可以確保它是正確的。而 Ruby 版的我就沒法確定它不會出錯了，必須得測試一下。而且它要長一倍，看起來也更複雜。
這就是人們使用 Shell 指令碼的原因，它簡單卻實用。下面是另一個例子：
curl https://nl.wikipedia.org/wiki/Lijst_van_Nederlandse_gemeenten | grep '^<li><a href=' | sed -r 's|<li><a href="/wiki/.+" title=".+">(.+)</a>.*</li>|\1|' | grep -Ev '(^Tabel van|^Lijst van|Nederland)'這個指令碼可以從維基百科上獲取荷蘭基層政權的列表。幾年前我寫了這個臨時的指令碼，用來快速生成一個資料庫，到現在它仍然可以正常執行，當時寫它並沒有花費我多少精力。但要用 Ruby 完成同樣的功能則會麻煩得多。
現在來說說 shell 的缺點吧。隨著程式碼量的增加，你的指令碼會變得越來越難以維護，但你也不會想用別的語言重寫一遍，因為你已經在這個 shell 版上花費了很多時間。
我把這種情況稱為“Shell 指令碼程式設計陷阱”，這是沉沒成本謬論的一種特例（LCTT 譯註：“沉沒成本謬論”是一個經濟學概念，可以簡單理解為，對已經投入的成本可能被浪費而念念不忘）。
實際上許多指令碼會增長到超出預期的大小，你經常會花費過多的時間來“修復某個 bug”，或者“新增一個小功能”。如此迴圈往復，讓人頭大。
如果你從一開始就使用 Python、Ruby 或是其他類似的語言來寫這個程式，你可能會在寫第一版的時候多花些時間，但以後維護起來就容易很多，bug 也肯定會少很多。
以我的 packman.vim 指令碼為例。它起初只包含一個簡單的用來遍歷所有目錄的 for 迴圈，外加一個 git pull，但在這之後就剎不住車了，它現在有 200 行左右的程式碼，這肯定不能算是最複雜的指令碼，但假如我一上來就按計劃用 Go 來編寫它的話，那麼增加一些像“列印狀態”或者“從組態檔裡克隆新的 git 庫”這樣的功能就會輕鬆很多；新增“並行克隆”的支援也幾乎不算個事兒了，而在 shell 指令碼裡卻很難實現（儘管不是不可能）。事後看來，我本可以節省時間，並且獲得更好的結果。
出於類似的原因，我很後悔寫出了許多這樣的 shell 指令碼，而我在 2018 年的新年誓言就是不要再犯類似的錯誤了。
需要指出的是，shell 程式設計的確存在一些實際的限制。下面是一些例子：
which 還是 command？該用 $@ 還是 $*，是不是得加引號？你是該用 cmd $arg 還是 cmd "$arg"？等等等等。/bin/sh 可能是 dash 或者 bash，不同的 shell 有不同的執行方式。外部工具如 grep、sed 等，不一定能支援同樣的引數。你能確定你的指令碼可以適用於 Linux、macOS 和 Windows 的所有版本嗎（無論是過去、現在還是將來）？$? 或是 set -e），排查一些超過“出了個小錯”級別的複雜錯誤幾乎是不可能的。set -u，變數未定義將不會報錯，而這會導致一些“搞笑事件”，比如 rm -r ~/$undefined 會刪除使用者的整個家目錄（瞅瞅 Github 上的這個悲劇）。bc 或 dc 這樣的外部工具（$(( .. )) 這種方式只能對付一下整數）。反饋
你可以發郵件到 [email protected]，或者在 GitHub 上建立 issue 來向我反饋，提問等。