作為一枚Linux嵌入式程序猿，寫shell腳本也是經(jīng)常碰到的工作，在這個過程中或多或少踩過一些坑，也積累了一些經(jīng)驗(yàn)，在此分享給大家，希望能對大家有點(diǎn)幫助。

1. 指定bash

我們知道在shell 腳本的第一行，都應(yīng)該指定bash，那#！之后到底應(yīng)該是什么呢？

這個問題估計(jì)不同的人的回答可能都不一樣。我見過/usr/bin/env bash，也見過/bin/bash，還有/usr/bin/bash，還有/bin/sh，還有/usr/bin/env sh。我自己也用過其中過的幾個，其實(shí)在很多情況下，以上幾種寫法效果都是相同的。但是，坑我們的往往就是少數(shù)情況~

如果恰好碰到系統(tǒng)的默認(rèn)shell不是bash怎么辦？比如某Linux發(fā)行版的某個版本，默認(rèn)的 sh 就不是 bash。如果系統(tǒng)的bash不是在/usr/bin/bash怎么辦？

還有關(guān)于bash和sh的一些小區(qū)別：

假設(shè)我們寫一小段腳本，看看運(yùn)行結(jié)果！

#！/bin/sh

source mlryj.sh

echo “hello world！”

執(zhí)行結(jié)果：

然后我們將腳本改成這樣

#！/bin/bash

source mlryj.sh

echo “hello world！”

執(zhí)行結(jié)果：

從結(jié)果看，在#！/bin/sh的情況下，在mlryj.sh這個腳本不存在的情況下，source不成功，不會運(yùn)行source后面的代碼。

而在#！/bin/bash的情況下，雖然source不成功，但是還是運(yùn)行了source后面的echo語句。

為什么會這樣呢？

接下來我們看一看/bin/sh是個什么東西。

從上面可以看到，sh只是bash的一個軟鏈接，在一般的linux系統(tǒng)當(dāng)中，sh調(diào)用執(zhí)行腳本相當(dāng)于打開了bash的posix模式，也就是說 /bin/sh 相當(dāng)于 /bin/bash --posix。posix的特定規(guī)范之一是，當(dāng)某行代碼出錯時，便不繼續(xù)往下解釋。

把腳本改成如下圖所示的格式，我們得到運(yùn)行結(jié)果和#！/bin/sh是一樣的。

#！/bin/bash --posix

source mlryj.sh

echo “hello world！”

推薦大家使用 /usr/bin/env bash 和 /bin/bash。前者通過env添加一個中間層，讓env在PATH中搜索bash；后者畢竟是有官方背書的，約定俗成的bash位置。但是當(dāng)腳本出現(xiàn)了錯誤怎么辦呢？請看Tip2。

2. set -e 和 set -x

好了，關(guān)于指定bash已經(jīng)完成了。接下來該開始寫shell腳本第二行、第三行。

小編建議：在你開始構(gòu)思并寫下具體的代碼邏輯之前，先插入一行“set -e”和一行“set -x”。

set -x會在執(zhí)行每一行shell腳本時，把執(zhí)行的內(nèi)容輸出來。它可以讓你看到當(dāng)前執(zhí)行的情況，里面涉及的變量也會被替換成實(shí)際的值。

set -e會在執(zhí)行出錯時結(jié)束程序，就像其他語言中的“拋出異?！币粯?。

這兩個組合在一起，可以在debug的時候替自己節(jié)省許多時間。出于防御性編程的考慮，有必要在寫第一行具體的代碼之前就插入它們。捫心自問，寫代碼的時候能夠一次寫對的次數(shù)有多少？大多數(shù)代碼，在提交之前，通常都經(jīng)歷過反復(fù)調(diào)試修改的過程。與其在焦頭爛額之際才引入這兩個配置，不如一開始就給調(diào)試留下余地。在代碼終于可以提交之后，再考慮是否保留它們也不遲。

#！/bin/sh

set -x

set -e

source mlryj.sh

echo “hello world！”

運(yùn)行結(jié)果如下：

3. shellcheck

加了set -x和set -e后，現(xiàn)在我已經(jīng)有了shell開始的三行代碼，但是具體的業(yè)務(wù)邏輯一行都沒寫。是不是該開始寫了？

且慢！工欲善其事，必先利其器。小編先給各位介紹一個shell腳本編寫神器：shellcheck

很慚愧，雖然這幾年寫了一些shell腳本，但是真正寫起來的時候還是有很多語法記不清楚。這時候就要依仗shellcheck了。

shellcheck除了可以提醒語法問題以外，還能檢查出shell腳本編寫常見的錯誤代碼。相信我，使用shellcheck會給我們的shell編寫能力帶來了巨大的飛躍的。

安裝方法如下圖：

安裝完成后可以通過shellcheck -V查看當(dāng)前安裝成功的版本號。如下圖：

雖然我們技能不如別人，但是我們可以升級裝備，在裝備上趕上并超過對方啊！有了shellcheck加持就好比真三中諸葛亮帶上了飛鞋，郭嘉買了孫子兵法，哈哈哈~~

4. 注意local

首先我們來看一下下面兩段代碼及運(yùn)行結(jié)果，代碼段1：

#！/bin/bash

set -x

set -e

function wgytest（）

{

a=$1

echo a

}

wgytest shell

echo “hello world！”

echo $a

運(yùn)行結(jié)果如下圖所示：

代碼段2：

#！/bin/bash

set -x

set -e

function wgytest（）

{

local a=$1

echo a

}

wgytest shell

echo “hello world！”

echo $a

運(yùn)行結(jié)果如下圖所示：

從上面的代碼可以看出，我們只是將函數(shù)wgytest中的變量a加了local限定詞，運(yùn)行結(jié)果可以看出，第二段代碼最后的echo并沒有輸出變量a的內(nèi)容。

這是因?yàn)樵赽ash，如果不加local限定詞，變量默認(rèn)都是全局的。在頂級作用域里，是否是全局變量并不重要。但是在函數(shù)里面，聲明一個全局變量可能會污染到其他作用域，尤其在你根本沒有注意到這一點(diǎn)的情況下。當(dāng)我們開始把重復(fù)的邏輯提煉成函數(shù)，這時就有可能會掉到bash的這一個坑里。所以，對于在函數(shù)內(nèi)聲明的變量，小編的建議是記得加上local限定詞。

5. 寫在最后

以上幾條都是具體的建議，這條來點(diǎn)虛的。

雖然使用shell可以方便快捷地實(shí)現(xiàn)各種復(fù)雜的功能，但也還是不得不依靠grep、sed、awk等各種工具把它們粘合在一起。實(shí)際上由于缺乏完善的數(shù)據(jù)結(jié)構(gòu)以及一致的API，shell腳本在處理復(fù)雜的邏輯上還是顯得力不從心。如果你的任務(wù)包含較為復(fù)雜的邏輯，而且數(shù)據(jù)結(jié)構(gòu)復(fù)雜，那么建議使用python之類的語言編寫腳本。

程序猿無論寫什么代碼，都要三思而行，切忌粗心大意。畢竟許多時候，我們的一個粗心就會給整個系統(tǒng)帶來一個悲劇，其實(shí)復(fù)雜的腳本也是發(fā)端于幾行小小的命令。一開始寫腳本的人，也許以為它只是一次性任務(wù)。代碼里難免對一些外部條件有些假定，在當(dāng)時也許是正常的，但是隨著外部環(huán)境的變化，這些就成了隱藏的雷。這就需要在編寫的時候辨清哪些是會變的依賴、哪些是腳本正常運(yùn)行所不可或缺的。同時要有防御性編程的意識，給自己的代碼一道護(hù)城河。