Bash程式設計易犯的錯誤

發表於2013-08-19
程式設計

前一段時間發現一個很好的wiki站點，上面有很多優秀的Bash文章。最近挑了一篇介紹Bash程式設計容易犯的各種錯誤的文章看，收穫很多，不敢獨享，把這篇文章以半翻譯半筆記的形式分享給大家。

 

1. for i in $(ls *.mp3)

Bash寫迴圈程式碼的時候，確實比較容易犯下面的錯誤：

這裡主要兩個問題：

我們不能避免某些檔名中包含空格，Shell會對$(ls *.mp3)展開的結果會被做單詞拆分(WordSplitting)的處理。假設有一個檔案，名字為01 – Don’t Eat the Yellow Snow.mp3，for迴圈處理的時候，會今次遍歷檔名中的每個單詞：01, -, Don’t, Eat等等：

比這更差的情況是，上面命令展開的結果可能被Shell進一步處理，比如檔名展開。比如，ls執行的結果中包含*號，按照萬用字元的規則, *號會被展開成當前目錄下的所有檔案:

不過，在這種場景下，你即使加上引號，也是無濟於事的：

加上引號後，ls執行的結果會被當成一個整體，所以for迴圈只會執行一次，達不到預期的效果。

事實上，這種情況下，根本不需要使用ls命令。ls命令的結果本身就設計成給人讀的，而不是給指令碼解析的。正確的處理方法是，直接使用檔名展開（萬用字元）的功能：

檔名展開是位於各種展開（花括號展開、變數替換、命令展開等）功能中的最後一個環節，所以不會有之前不帶引號的命令展開的副作用。如果你需要遞迴地處理檔案，可以考慮使用Find命令。

到這一步，之間的問題看樣子已經修復了。但是，如果你進一步思考，假設當前目錄上沒有檔案時會怎麼樣？沒有檔案的時候，*.mp3不會被展開直接傳遞給for迴圈處理，所以這個時候迴圈還是會執行一次。這種情況不是我們預期的行為。保險起見，可以在迴圈處理的時候，檢查下檔案是否存在：

如果你有使用引號和避免單詞拆分的習慣，你完全可以避免很多錯誤。

注意下迴圈體內部的”$i”，這裡會導致下面我們要說的另外一個比較容易犯的錯誤。

2. cp $file $target

上面的命令有什麼問題呢？如果你提前知道，$file和$target檔名中不會包含空格或者*號。否則，這行命令執行前在經過單詞拆分和檔名展開的時候會出現問題。所以，兩次強調，在使用展開的地方切勿忘記使用引號：

如果不帶引號，當你執行如下命令時就會出錯：

如果帶上引號，就不會有上面的問題，除非檔名以’-‘開頭，在這種情況下，cp會認為你提供的是一個命令列選項，這個錯誤下面會介紹。

3. 檔名中包含短橫’-‘

檔名以’-‘開頭會導致許多問題，*.mp3這種萬用字元會根據當前的locale展開成一個列表，但在絕大多數環境下，’-‘排序的時候會排在大多數字母前。這個展開的列表傳遞給有些命令的時候，會錯誤的將-filename解析成命令列選項。這裡有兩種方法來解決這個問題。

第一種方法是在命令和引數之間加上–，這種語法告訴命令不要繼續對–之後的內容進行命令列引數/選項解析：

這種方法可以解這個問題，但是你需要在每個命令後面都要加上–，而且依賴具體的命令解析的方式，如果一些命令不相容這種約定俗成的規範，這種做法是無效的。

另外一種方法是，確保檔名都使用相對或者絕對的路徑，以目錄開頭：

這種情況下，即使某個檔案以-開頭，展開後檔名依然是./-foo.mp3這種形式，完全不會有問題。

4. [ $foo = “bar” ]

這是一個與第2個問題類似的問題，雖然用到了引號，但是放錯了位置，對於字串字面值，除非有特殊符號，否則不大需要用引號括起來。但是，你應該把變數的值用括號括起來，從而避免它們包含空格或能萬用字元，這一點我們在前面的問題中都解釋過。

這個例子在以下情況下會出錯：

  • 如果[中的變數不存在，或者為空，這個時候上面的例子最終解析結果是：

    並且執行會出錯：unary operator expected，因為=是二元操作符，它需要左右各一個運算元。
  • 如果變數值包含空格，它首先在執行之前進行單詞拆分，因此[命令看到的樣子可能是這樣的：

正確的做法應該是：

這種寫法，在POSIX相容的實現中都不會有問題，即使$foo以短橫”-“開頭，因為POSIX實現的test命令通過傳遞的引數來確定執行的行為。

只有一些非常古老的shell可能會遇到問題，這個時候你可以使用下面的寫法來解決（相信你肯定看到過這種寫法）：

在Bash中，還有另外一種選擇是使用[[關鍵字：

這裡你不需要使用引號，因為在[[裡面引數不會進行展開，當然帶上引號也不會有錯。

不過有一點要注意的是，[[裡的==不僅僅是文字比較，它會檢查左邊的值是否匹配右側的表示式，==右側的值加上引號，會讓它成為一個普通的字面量，*?等萬用字元會失去特殊含義。

5. cd $(dirname “$f”)

這又是一個引號的問題，命令展開的結果會進一步地進行單詞拆分或者檔名展開。因此下面的寫法才是正確的：

但是，上面引號的寫法可能比較怪異，你可能會認為第一、二個引號，第三、四個引號是一組的。

但是事實上，Bash將命令替換裡面的引號當成一組，外面的當成另外一組。如果你是用反引號的寫法，引號的行為就不是這樣的了，所以$()寫法更加推薦。

6. [ “$foo” = bar && “$bar” = foo ]

不要在test命令內部使用&&，Bash解析器會把你的命令分隔成兩個命令，在&&之前和之後。你應該使用下面的寫法：

儘量避免使用下面的寫法，雖然它是正確的，但是這種寫法可移植性不好，並且已經在POSIX-2008中被廢棄：

7. [[ $foo > 7 ]]

原文作者認為算術比較不應該用[[，而是用((，我沒弄明白是為什麼。

如果有理解的同學，歡迎以評論回覆，謝謝。

8. grep foo bar | while read -r; do ((count++)); done

這種寫法初看沒有問題，但是你會發現當執行完後，count變數並沒有變化。原因是管道後面的命令是在一個子Shell中執行的。

POSIX規範並沒有說明管道的最後一個命令是不是在子Shell中執行的。一些shell，例如ksh93或者Bash>=4.2可以通過shopt -s lastpipe命令，指明管道中的最後一個命令在當前shell中執行。由於篇幅限制，在此就不展開，有興趣的可以看Bash FAQ #24。

9. if [grep foo myfile]

初學者會錯誤地認為，[是if語法的一部分，正如C語言中的if ()。但是事實並非如此，if後面跟著的是一個命令，[是一個命令，它是內建命令test的簡寫形式，只不過它要求最後一個引數必須是]。下面兩種寫法是一樣的：

兩個都是檢查引數”false”是不是非空的，所以上面兩個語句都會輸出HELP。

if語句的語法是：

再次強調，[是一個命令，它同其它常規的命令一樣接受引數。if是一個複合命令，它包含其它命令，[並不是if語法中的一部分。

如果你想根據grep命令的結果來做事情，你不需要把grep放到[裡面，只需要在if後面緊跟grep即可：

如果grep在myfile中找到匹配的行，它的執行結果為0(true)，then後面的部分就會執行。

10. if [bar=”$foo”]; then …

正如上一個問題中提到的，[是一個命令，它的引數之間必須用空格分隔。

11. if [ [ a = b ] && [ c = d ] ]; then …

不要用把[命令看成C語言中if語句的條件一樣，它是一個命令。

如果你想表達一個複合的條件表示式，可以這樣寫：

注意，if後面有兩個命令，它們用&&分開。等價於下面的寫法：

如果第一個test(或者[)命令返回false，then後面的語句不會執行；如果第一個返回true，第二個test命令會執行；只有第二個命令同樣返回true的情況下，then後面的語句才會執行。

除此之外，還可以使用[[關鍵字，因為它支援&&的用法：

12. read $foo

read命令中你不需要在變數名之前使用$。如果你想把讀入的資料存放到名為foo的變數中，下面的寫法就夠了：

或者，更加安全地方法：

read $foo會把一行的內容讀入到變數中，該變數的名稱儲存在$foo中。所以兩者的含義是完全不一樣的。

13. cat file | sed s/foo/bar/ > file

你不應該在一個管道中，從一個檔案讀的同時，再往相同的檔案裡面寫，這樣的後果是未知的。

你可以為此建立一個臨時檔案，這種做法比較安全可靠：

或者，如果你用得是 GNU Sed 4.x 以上的版本，可以使用-i 選項即時修改檔案的內容：

14. echo $foo

這種看似無害的命令往往會給初學者千萬極大的困擾，他們會懷疑是不是因為 $foo 變數的值是錯誤的。事實卻是因為，$foo 變數在這裡沒有使用雙引號，所以在解析的時候會進行單詞拆分和檔名展開，最終導致執行結果與預期大相徑庭：

這裡整句話會被拆分成單詞，然後其中的萬用字元會被展開，例如*.zip。當你的使用者看到如下的結果時，他們會怎樣想：

再舉一個例子（假設當前目錄下有以 .zip 結尾的檔案）：

實際上，這裡使用 echo 命令並不是絕對的安全。例如，當變數的值包含-n時，echo 會認為它是一個合法的選項而不是要輸出的內容（當然如果你能夠保證不會有-n 這種值，可以放心地使用 echo 命令）。

完全可靠的列印變數值的方法是使用 printf：

15. $foo=bar

略過

16. foo = bar

當賦值時，等號兩邊是不允許出現空格的，這同 C 語言不一樣。當你寫下 foo = bar 時，shell 會將該命令解析成三個單詞，然後第一個單詞 foo 會被認為是一個命令，後面的內容會被當作命令引數。

同樣地，下面的寫法也是錯誤的：

17. echo <<EOF

當指令碼需要嵌入大段的文字內容時，here document往往是一個非常有用的工具，它將其中的文字作為命令的標準輸入。不過，echo 命令並不支援從標準輸入讀取內容，所以下面的寫法是錯誤的：

正確的方法是，使用 cat 命令來完成：

或者可以使用雙引號，它也可以跨越多行，而且因為 echo 命令是內建命令，相同情況下它會更加高效：

18. su -c ‘some command’

這種寫法“幾乎”是正確的。問題是，在許多平臺上，su 支援 -c 引數，但是它不一定是你認為的。比如，在 OpenBSD 平臺上你這樣執行會出錯：

在這裡，-c是用於指定login-class。如果你想要傳遞 -c ‘some command’ 給 shell，最好在之前顯示地指定 username：

19. cd /foo; bar

如果你不檢查 cd 命令執行是否成功，你可以會在錯誤的目錄下執行 bar 命令，這有可能會帶來災難，比如 bar 命令是 rm -rf *。

你必須經常檢查 cd 命令執行是否有錯誤，簡單的做法是：

如果在 cd 命令後有多個命令，你可以選擇這樣寫：

出錯時，cd 命令會報告無法改變當前目錄，同時將錯誤訊息輸出到標準錯誤，例如”bash: cd: /foo: No such file or directory”。如果你想要在標準輸出同時輸出自定義的錯誤提示，可以使用複合命令（command grouping）:

注意，在{號和 echo 之間需要有一個空格，同時}之前要加上分號。

順便提一下，如果你要在指令碼里頻繁改變當前目錄，可以看看 pushd/popd/dirs 等命令，可能你在程式碼裡面寫的 cd/pwd 命令都是沒有必要的。

說到這，比較下下面兩種寫法：

下面的寫法，在迴圈中 fork 了一個子 shell 程式，子 shell 程式中的 cd 命令僅會影響當前 shell的環境變數，所以父程式中的環境命令不會被改變；當執行到下一次迴圈時，無論之前的 cd 命令有沒有執行成功，我們會回到相同的當前目錄。這種寫法相較前面的用法，程式碼更加乾淨。

20. [ bar == “$foo” ]

正確的用法:

21. for i in {1..10}; do ./something &; done

你不應該在&後面新增分號，刪除它：

或者改成多行的形式：

&和分號一樣也可以用作命令終止符，所以你不要將兩個混用到一起。一般情況下，分號可以被換行符替換，但是不是所有的換行符都可以用分號替換。

22. cmd1 && cmd2 || cmd3

有些人喜歡把&&和||作為if…then…else…fi 的簡寫語法，在多數情況下，這種寫法沒有問題。例如：

但是，這種結構並不是在所有情況下都完全等價於 if…fi 語法。這是因為在&&後面的命令執行結束時也會生成一個返回碼，如果該返回碼不是真值（0代表 true），||後面的命令也會執行，例如：

看起來上面的結果應該是返回1，但是結果卻是輸出0，為什麼呢？原因是這裡 i++ 和 i– 都執行了一遍。

其中，((i++))命令執行算術運算，表示式計算的結果為0。這裡和 C 語言一樣，表示式的結果為0被認為是 false。所以當 i=0 的時候，((i++))命令執行的返回碼為1（false），從而會執行接下來的((i–))命令。

如果我們在這裡使用字首自增運算子的話，返回的結果恰恰為1，因為((++i))執行的返回碼是0（true）：

不過在你無法保證 y 的執行結果是，絕對不要依靠 x && y || z這種寫法。上面這種巧合，在 i 初始化為-1時也會有問題。

如果你喜歡程式碼更加安全健壯，建議使用 if…fi 語法：

23. echo “Hello World!”

在互動式的 Shell 環境下，你執行以上命令會遇到下面的錯誤：

這是因為，在預設的互動式 Shell 環境下，Bash 發現感嘆號時會執行歷史命令展開。在 Shell 指令碼中，這種行為是被禁止的，所以不會發生錯誤。

不幸地是，你認為明顯正確地修復方法，也不能工作，你會發現反斜槓並沒有轉義感嘆號：

最簡單地方法是禁用 histexpand 選項，你可以通過 set +H 或者 set +o histexpand 命令來完成。

下面四種寫法都可以解決：

24. for arg in $*

和大多數 Shell 一樣，Bash 支援依次讀取單個命令列引數的語法。不過這並是$*或者$@，這兩種寫法都不正確，它們只能得到完整的引數列表，並非單獨的一個個引數。

正確的語法是（沒錯要加上引號）：

在指令碼中遍歷所有引數是一個再普遍不過的需求，所以 for arg 預設等價於 for arg in “$@”。$@使用雙引號後就有特殊的魔力，每個引數展開後成為一個獨立的單詞。（”$@”等價於”$1” “$2” “$3” …）

下面是一個錯誤的例子:

執行的結果為：

正確的寫法：

執行的結果為：

上面正確的例子中，第一個引數’arg 1’在展開後依然是一個獨立的單詞，而不會被拆分成兩個。

25. function foo()

這種寫法不一定能夠相容所有 shell，相容的寫法是：

26. echo “~”

波浪號展開（Tilde expansion）僅當~沒有引號的時候發生，在上面的例子中，只會向標準輸出列印~符號，而不是當前使用者的家目錄路徑。

當用引號將路徑引數引起來時，
如果要用引號將相對於家目錄的路徑引起來時，推薦使用 $HOME 而不是 ~, 假如 $HOME 目錄是”/home/my photos”，路徑中包含空格。

下面是幾組例子：

27. local varname=$(command)

當在函式中宣告區域性變數時，local作為一個獨立的命令，這種奇特的行為有時候可能會導致困擾。比如，當你想要捕獲命令替換的返回碼時，你就不能這樣做。local命令的返回碼會覆蓋它。

這種情況下，你只能分成兩行寫：

28. export foo=~/bar

export 與 local 命令一樣，並不是賦值語句的一部分。因此，在有些 Shell 下（比如Bash），export foo=~/bar會展開，但是有些（比如 Dash）卻不行。

下面是兩種比較健壯的寫法：

29. sed ‘s/$foo/good bye/’

單引號內部不會展開 $foo變數，在這裡可以換成雙引號：

但是要注意，如果你使用了雙引號，就需要考慮更多轉義的事情，具體可以看Quotes這一頁。.

30. tr [A-Z] [a-z]

這裡至少有三個問題。第一個問題是， [A-Z] 和 [a-z] 會被 shell 認為是萬用字元。如果在當前目錄下沒用檔名為單個字母的檔案，這個命令似乎能正確執行，否則會錯誤地執行，也許你會在週末耗費許多小時來修復這個問題。

第二個問題是，這不是 tr 命令正確的寫法，實際上，上面的命令會把[轉換成[，將任意大寫字元轉換成對應的小寫字元，將]轉換成]，所以你根本不需要加上括號，這樣第一個問題就可以解決了。

第三個問題是，上面的命令執行結果依賴於當前的 locale，A-Z 或者 a-z 不一定會代表26個 ASCII 字母。實際上，在一些語言環境下，z 位於字母表的中間位置。這個問題的解法，取決於你希望發生的行為是哪一種。

如果你僅希望改變26個英文字母的大小寫（強制 locale為 C）：

如果你希望根據實際的語言環境來轉換：

31. ps ax | grep gedit

這裡的根本問題是正在執行的程式名稱，本質上是不可靠的。可能會有多個合法的gedit程式，也有可能是別的東西偽裝成gedit程式（改變執行命令名稱是一件簡單的事情 ）,更多細節可以看ProcessManagement這一篇文章。

執行以上命令，往往會在結果中包含 grep 程式：

這個時候，需要過濾多餘的結果：

上面的寫法比較醜陋，另外一種方法是：

32. printf “$foo”

如果$foo 變數的值中包括\或者%符號，上面命令的執行結果可能會出乎你的意料之外。

下面是正確的寫法：

33. for i in {1..$n}

Bash的命令直譯器會優先展開大括號，所以這時大括號{}表示式裡面看到的是文字上的$n（沒有展開）。$n 不是一個數值，所以這裡的大括號{}並不會展開成數字列表。可見，這導致很難使用大括號來展開大小隻能在執行時才知道的列表。

可以用下面的方法：

注：之前我也有寫過一篇文章來介紹這個問題：Shell生成數字序列。

34. if [[ $foo = $bar ]]

在[[內部，當=號右邊的值沒有用引號引起來，bash 會將它當作模式來匹配，而不是一個簡單的字串。所以，在上面的例子中 ，如果 bar 的值是一個*號，執行的結果永遠是 true。

所以，如果你想檢查兩側的字串是否相同，等號右側的值一定要用引號引起來。

如果你確實要執行模式匹配，聰明的做法是取一個更加有意義的變數名（例如$patt），或者加上註釋說明。

35. if [[ $foo =~ ‘some RE’ ]]

同上，如果=~號右側的值加上引號，它會散失特殊的正規表示式含義，而變成一個普通的字串。

如果你想使用一個長的或者複雜的正規表示式，避免大量的反斜槓轉義，建議把它放在一個變數中：

36. [ -n $foo ] or [ -z $foo ]

這個例子中，$foo 沒有用引號引起來，當$foo包含空格或者$foo為空時都會出問題：

正確的寫法是：

37. [[ -e “$broken_symlink” ]] returns 1 even though $broken_symlink exists

這裡-e 選項是看檔案是否存在，當緊跟的檔案是一個軟連結時，它不看軟連結是否存在，而是看實際指向的檔案是否存在。所以當軟連結損壞時，即實際指向的檔案被刪除後，-e 的結果返回1。

所以如果你確實要判斷後面的檔案是否存在，正確的寫法是：

38. ed file <<<“g/d\{0,3\}/s//e/g” fails

ed 命令使用的正則語法，不支援0次出現次數，下面的就可以正常工作：

略過，現在很少會有人用 ed 命令吧。

39. expr sub-string fails for “match”

下面的例子多數情況下執行不會有問題：

但是當 $work 不巧剛好是 match 時，就有可能出錯了（MAC OSX 下的 expr 命令不支援 match，所以依然能正常工作）：

原因是 match 是 expr 命令裡面的一個特殊關鍵字，針對 GNU系統，解決方法是在前面加一個’+’：

‘+’號可以讓 expr 命令忽略後續 token 的特殊含義。

另外一個建議是，不要再使用 expr 命令了，expr 能做的事情都可以用 Bash 原生支援的引數展開（Parameter Expansion）或者字串展開（Substring Expansion）來完成。並且相同情況下，內建的功能肯定比外部命令的效率要高。

上面的例子，目的是為了刪除單詞中的首字元，可以這樣做：

40. On UTF-8 and Byte-Order Marks (BOM)

多數情況下，UNIX 下 UTF-8 型別的文字不需要使用 BOM，文字的編碼是根據當前語言環境，MIME型別或者其它檔案後設資料資訊確定的。人為閱讀時，不會因為在檔案開始處加 BOM 標記而腚影響，但是當檔案要被指令碼解釋執行時，BOM 標記會像 MS-DOS 下的換行符（^M）一樣奇怪。

41. content=$(<file)

這裡沒有什麼錯誤，不過你要知道命令替換會刪除結尾多餘的換行符。

略過，原文給的優化方法需要 Bash 4.2+ 以上的版本，手頭沒有這樣的環境。

42. somecmd 2>&1 >>logfile

這是一個很常見的錯誤，顯然你本來是想將標準輸出與標準錯誤輸出都重定向到檔案logfile 中，但是你會驚訝地發現，標準錯誤依然輸出到螢幕中。

這種行為的原因是，重定向在命令執行之前解析，並且是從左往右解析。上面的命令可以翻譯成，將標準錯誤輸出重定向到標準輸出（此刻是終端），然後將標準輸出重定向到檔案 logfile 中。所以，到最後，標準錯誤並沒有重定向到檔案中，而是依然輸出到終端：

更加詳細的說明見BashFAQ。

43. cmd; (( ! $? )) || die

只有需要捕獲上一個命令的執行結果進，才需要記錄$?的值，否則如果你只需要檢查上一個命令是否執行成功，直接檢測命令：

或者使用 case 語句來檢測多個或能的返回碼：

相關文章