目錄
由於工作需要，最近重新開始拾掇shell指令碼。雖然絕大部分命令自己平時也經常使用，但是在寫成指令碼的時候總覺得寫的很難看。而且當我在看其他人寫的指令碼的時候，總覺得難以閱讀。畢竟shell指令碼這個東西不算是正經的程式語言，他更像是一個工具，用來雜糅不同的程式供我們呼叫。
因此很多人在寫的時候也是想到哪裏寫到哪裏，基本上都像是一段超長的main函數，不忍直視。同時，由於歷史原因，shell有很多不同的版本，而且也有很多有相同功能的命令需要我們進行取捨，以至於程式碼的規範很難統一。
考慮到上面的這些原因，我查閱了一些相關的文件，發現這些問題其實很多人都考慮過，而且 也形成了一些不錯的文章，但是還是有點零散。因此我就在這裏把這些文章稍微整理了一下，作爲以後我自己寫指令碼的技術規範。
開頭有「蛇棒」
所謂shebang其實就是在很多指令碼的第一行出現的以#!開頭的註釋，他指明瞭當我們沒有指定直譯器的時候預設的直譯器，一般可能是下面 下麪這樣：
#!/bin/bash
當然，直譯器有很多種，除了bash之外，我們可以用下面 下麪的命令檢視本機支援的直譯器:
$ cat /etc/shells
#/etc/shells: valid login shells
/bin/sh
/bin/dash
/bin/bash
/bin/rbash
/usr/bin/screen
當我們直接使用./a.sh來執行這個指令碼的時候，如果沒有shebang，那麼它就會預設用$SHELL指定的直譯器，否則就會用shebang指定的直譯器。
這種方式是我們推薦的使用方式。
註釋，顯然是一個常識，不過這裏還是要再強調一下，這個在shell指令碼裡尤爲重要。因爲很多單行的shell命令不是那麼淺顯易懂，沒有註釋的話在維護起來會讓人尤其的頭大。
註釋的意義不僅在於解釋用途，而在於告訴我們注意事項，就像是一個README。
具體的來說，對於shell指令碼，註釋一般包括下面 下麪幾個部分：
shebang
指令碼的參數
指令碼的用途
指令碼的注意事項
指令碼的寫作時間，作者，版權等
各個函數前的說明註釋
一些較複雜的單行命令註釋
這一點很重要，當我們的指令碼需要接受參數的時候，我們一定要先判斷參數是否合乎規範，並給出合適的回顯，方便使用者瞭解參數的使用。
最少，最少，我們至少得判斷下參數的個數吧：
if [[ $# != 2 ]];then
echo "Parameter incorrect."
exit 1
fi
一般情況下我們會將一些重要的環境變數定義在開頭，確保這些變數的存在。
source /etc/profile
export PATH=」/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/apps/bin/」
這種定義方式有一個很常見的用途，最典型的應用就是，當我們本地安裝了很多java版本時，我們可能需要指定一個java來用。那麼這時我們就會在指令碼開頭重新定義JAVA_HOME以及PATH變數來進行控制。同時，一段好的程式碼通常是不會有很多寫死在程式碼裡的「魔數」的。如果一定要有，通常是用一個變數的形式定義在開頭，然後呼叫的時候直接呼叫這個變數，這樣方便日後的修改。
對於shell指令碼，縮排是個大問題。因爲很多需要縮排的地方(比如if,for語句)都不長，所有很多人都懶得去縮排，而且很多人不習慣用函數，導致縮排功能被弱化。
其實正確的縮排是很重要的，尤其是在寫函數的時候，否則我們在閱讀的時候很容易把函數體跟直接執行的命令搞混。
常見的縮排方法主要有」soft tab」和」hard tab」兩種。
所謂soft tab就是使用n個空格進行縮排(n通常是2或4)
所謂hard tab當然就是指真實的\t字元
這裏不去撕哪種方式最好，只能說各有各的優劣。反正我習慣用hard tab。
對於if和for語句之類的，我們最好不要把then，do這些關鍵字單獨寫一行，這樣看上去比較醜。。。
所謂命名規範，基本包含下面 下麪這幾點：
檔名規範，以.sh結尾，方便識別
變數名字要有含義，不要拼錯
統一命名風格，寫shell一般用小寫字母加下劃線
在寫指令碼的時候儘量使用UTF-8編碼，能夠支援中文等一些奇奇怪怪的字元。不過雖然能寫中文，但是在寫註釋以及打log的時候還是儘量英文，畢竟很多機器還是沒有直接支援中文的，打出來可能會有亂碼。這裏還尤其需要注意一點，就是當我們是在windows下用utf-8編碼來寫shell指令碼的時候，一定要注意這個utf-8是否是有BOM的。預設情況下windows判斷utf-8格式是通過在檔案開頭加上三個EF BB BF位元組來判斷的，但是在Linux中預設是無BOM的。因此如果我們是在windows下寫指令碼的時候，一定要注意將編碼改成Utf-8無BOM，一般用notepad++之類的編輯器都能改。否則，在Linux下執行的時候就會識別到開頭的三個字元，從而報一些無法識別命令的錯。當然，對於跨平臺寫指令碼還有一個比較常見的問題就是換行符不同。windows預設是\r\n而unix下是\n。不過有兩個小工具可以非常方便的解決這個問題：dos2unix,unix2dos。
這一點雖然很小，但是我個人卻經常忘記，不加執行許可權會導致無法直接執行，有點討厭。。。
日誌的重要性不必多說，能夠方便我們回頭糾錯，在大型的專案裡是非常重要的。
如果這個指令碼是供使用者直接在命令列使用的，那麼我們最好還要能夠在執行時實時回顯執行過程，方便使用者掌控。
有時候爲了提高使用者體驗，我們會在回顯中新增一些特效，比如顏色啊，閃爍啊之類的，具體可以參考ANSI/VT100 Control sequences這篇文章的介紹。
不要把密碼寫死在指令碼裡，不要把密碼寫死在指令碼裡，不要把密碼寫死在指令碼裡。
重要的事情說三遍，尤其是當指令碼託管在類似Github這類平臺中時。。。
在呼叫某些程式的時候，參數可能會很長，這時候爲了保證較好的閱讀體驗，我們可以用反斜槓來分行：
./configure \
–prefix=/usr \
–sbin-path=/usr/sbin/nginx \
–conf-path=/etc/nginx/nginx.conf \
注意在反斜槓前有個空格。
在使用命令的時候要瞭解命令的具體做法，尤其當數據處理量大的時候，要時刻考慮該命令是否會影響效率。
比如下面 下麪的兩個sed命令：
sed -n '1p' file
sed -n '1p;1q' file
他們的作用一樣，都是獲取檔案的第一行。但是第一條命令會讀取整個檔案，而第二條命令只讀取第一行。當檔案很大的時候，僅僅是這樣一條命令不一樣就會造成巨大的效率差異。
當然，這裏只是爲了舉一個例子，這個例子真正正確的用法應該是使用head -n1 file命令。。。
幾乎所有的大佬都推薦在使用」$」來獲取變數的時候最好加上雙引號。
不加上雙引號在很多情況下都會造成很大的麻煩，爲什麼呢？舉一個例子：
#!/bin/sh
#已知當前資料夾有一個a.sh的檔案
var="*.sh"
echo $var
echo "$var"
他的執行結果如下：
a.sh
*.sh
爲啥會這樣呢？其實可以解釋爲他執行了下面 下麪的命令：
echo *.sh
echo "*.sh"
在很多情況下，在將變數作爲參數的時候，一定要注意上面這一點，仔細體會其中的差異。上面只是一個非常小的例子，實際應用的時候由於這個細節導致的問題實在是太多了。。。
我們知道，像java，C這樣的編譯型語言都會有一個函數入口，這種結構使得程式碼可讀性很強，我們知道哪些直接執行，那些是函數。但是指令碼不一樣，指令碼屬於解釋性語言，從第一行直接執行到最後一行，如果在這當中命令與函數糅雜在一起，那就非常難讀了。
用python的朋友都知道，一個合乎標準的python指令碼大體上至少是這樣的：
#!/usr/bin/env python
def func1():
pass
def func2():
pass
if __name__=='__main__':
func1()
func2()
他用一個很巧妙的方法實現了我們習慣的main函數，使得程式碼可讀性更強。
在shell中，我們也有類似的小技巧:
#!/usr/bin/env bash
func1(){
#do sth
}
func2(){
#do sth
}
main(){
func1
func2
}
main "$@"
我們可以採用這種寫法，同樣實現類似的main函數，使得指令碼的結構化程度更好。
shell中預設的變數作用域都是全域性的，比如下面 下麪的指令碼：
#!/usr/bin/env bash
var=1
func(){
var=2
}
func
echo $var
他的輸出結果就是2而不是1，這樣顯然不符合我們的編碼習慣，很容易造成一些問題。
因此，相比直接使用全域性變數，我們最好使用local readonly這類的命令，其次我們可以使用declare來宣告變數。這些方式都比使用全域性方式定義要好。
在使用函數的時候一定要注意，shell中函數的返回值只能是整數，估計是因爲一般情況下一個函數的返回值通常表示這個函數的執行狀態，所以一般都是0或者是１就夠了，因此就設計成了這樣。不過，如果非得想傳遞字串，也可以通過下面 下麪變通的方法:
func(){
echo "2333"
}
res=$(func)
echo "This is from $res."
這樣，通過echo或者print之類的就可以做到傳一些額外參數的目的。
什麼叫間接參照？比如下面 下麪這個場景：
VAR1="2323232"
VAR2="VAR1"
我們有一個變數VAR1，又有一個變數VAR2，這個VAR2的值是VAR1的名字，那麼我們現在想通過VAR2來獲取VAR1的值，這時候應該怎麼辦呢？
比較土鱉的方法是這樣：
eval echo \$$VAR2
啥意思呢？其實就是構造了一個字串echo XXX，這個XXX就是XXX」，這個XXX就是VAR2的值VAR1，然後再用eval強制解析，這樣就做到了變相取值。
這個用法的確可行，但是看起來十分的不舒服，很難直觀的去理解，我們並不推薦。而且事實上我們本身就不推薦使用eval這個命令。
比較舒服的寫法是下面 下麪這樣:
echo ${!VAR1}
通過在變數名前加一個!就可以做到簡單的間接參照了。
不過需要注意的是，用上面的方法，我們只能夠做到取值，而不能做到賦值。如果想要做到賦值，還要老老實實的用eval來處理:
VAR1=VAR2
eval $VAR1=233
echo $VAR2
所謂heredocs，也可以算是一種多行輸入的方法，即在」<<」後定一個識別符號，接着我們可以輸入多行內容，直到再次遇到識別符號爲止。
使用heredocs，我們可以非常方便的生成一些模板檔案：
cat>>/etc/rsyncd.conf << EOF
log file = /usr/local/logs/rsyncd.log
transfer logging = yes
log format = %t %a %m %f %b
syslog facility = local3
EOF
很多情況下，我們會先獲取當前指令碼的路徑，然後以這個路徑爲基準，去找其他的路徑。通常我們是直接用pwd以期獲得指令碼的路徑。
不過其實這樣是不嚴謹的，pwd獲得的是當前shell的執行路徑，而不是當前指令碼的執行路徑。
正確的做法應該是下面 下麪這兩種：
script_dir=$(cd $(dirname $0) && pwd)
script_dir=$(dirname $(readlink -f $0 ))
應當先cd進當前指令碼的目錄然後再pwd，或者直接讀取當前指令碼的所在路徑。
這裏的簡短不單單是指程式碼長度，而是隻用到的命令數。原則上我們應當做到，能一條命令解決的問題絕不用兩條命令解決。這不僅牽涉到程式碼的可讀性，而且也關乎程式碼的執行效率。
最最經典的例子如下：
cat /etc/passwd | grep root
grep root /etc/passwd
cat命令最爲人不齒的用法就是這樣，用的沒有任何意義，明明一條命令可以解決，他非得加根管道。。。
其實程式碼簡短在還能某種程度上能保證效率的提升，比如下面 下麪的例子：
#method1
find . -name '*.txt' |xargs sed -i s/233/666/g
find . -name '*.txt' |xargs sed -i s/235/626/g
find . -name '*.txt' |xargs sed -i s/333/616/g
find . -name '*.txt' |xargs sed -i s/233/664/g
#method1
find . -name '*.txt' |
xargs sed -i "s/233/666/g;s/235/626/g;s/333/616/g;s/233/664/g"
這兩種方法做的事情都一樣，就是查詢所有的.txt後綴的檔案並做一系列替換。前者是多次執行find，後者是執行一次find，但是增加了sed的模式串。第一種更直觀一點，但是當替換的量變大的時候，第二種的速度就會比第一種快很多。這裏效率提升的原因，就是第二種只要執行一次命令，而第一種要執行多次。並且，巧用xargs命令，我們還可以十分方便的進行並行化處理:
find . -name '*.txt' |xargs -P $(nproc) sed -i "s/233/666/g;s/235/626/g;s/333/616/g;s/233/664/g"
通過-P參數指定並行度，可以進一步加快執行效率。
當我們需要充分考慮執行效率時，我們可能需要在執行命令的時候考慮並行化。shell中最簡單的並行化是通過」&」以及」wait」命令來做:
func(){
#do sth
｝
for((i=0;i<10;i++))do
func &
done
wait
當然，這裏並行的次數不能太多，否則機器會卡死。稍微正確的做法比較複雜，以後再討論，如果圖省事可以使用parallel命令來做，或者是用上面提到的xargs來處理。
我們知道，當我們想在資料夾下所有的txt檔案中檢索某一個字串(比如233)的時候，我們可能會用類似這樣的命令：
find . -name '*.txt' -type f | xargs grep 2333
很多情況下，這個命令會想我們所想的找到對應的匹配行，但是我們需要注意兩個小問題。
find命令會符合要求的匹配檔名，但是如果檔名包含空格，這時候將檔名傳給grep的時候就會有問題，這個檔案就會被當成兩個參數，這時候就要加一層處理，保證用空格分開的檔名不會被當成兩個參數：
find . -type f|xargs -i echo '"{}"'|xargs grep 2333
有時候，檔案的字元集可能跟終端的字元集不一致，這時候就會導致grep在搜尋時將檔案當成二進制檔案從而報binary file matches之類的問題。這時候要麼用iconv之類的字元集轉換工具將字元集進行切換，要麼就在不影響查詢的情況下對grep加-a參數，將所有檔案看成文字檔案:
find . -type f|xargs grep -a 2333
這裏的新寫法不是指有多厲害，而是指我們可能更希望使用較新引入的一些語法，更多是偏向程式碼風格的，比如
儘量使用func(){}來定義函數，而不是func{}
儘量使用[[]]來代替[]
儘量使用$()將命令的結果賦給變數，而不是反引號
在複雜的場景下儘量使用printf代替echo進行回顯
事實上，這些新寫法很多功能都比舊的寫法要強大，用的時候就知道了。
考慮到還有很多零碎的點，就不一一展開了，這裏簡單提一提。
路徑儘量保持絕對路徑，絕多路徑不容易出錯，如果非要用相對路徑，最好用./修飾
優先使用bash的變數替換代替awk sed，這樣更加簡短
簡單的if儘量使用&& ||，寫成單行。
比如[[ x > 2]] && echo x
當export變數時，儘量加上子指令碼的namespace，保證變數不衝突
會使用trap捕獲信號，並在接受到終止信號時執行一些收尾工作
使用mktemp生成臨時檔案或資料夾
利用/dev/null過濾不友好的輸出資訊
會利用命令的返回值判斷命令的執行情況
使用檔案前要判斷檔案是否存在，否則做好例外處理
不要處理ls後的數據(比如ls -l | awk ‘{ print $8 }’)，ls的結果非常不確定，並且平臺有關
讀取檔案時不要使用for loop而要使用while read
使用cp -r命令複製資料夾的時候要注意如果目的資料夾不存在則會建立，如果存在則會複製到該檔案的子資料夾下
爲了從制度上保證指令碼的品質，我們最簡單的想法大概就是搞一個靜態檢查工具，通過引入工具來彌補開發者可能存在的知識盲點。
市面上對於shell的靜態檢查工具還真不多，找來找去就找到一個叫shellcheck的工具，開源在github上，有8K多的star，看上去還是十分靠譜的。我們可以去他的主頁瞭解具體的安裝和使用資訊。
這個工具的對不同平臺的支援力度都很大，他至少支援了Debian,Arch,Gentoo,EPEL,Fedora,OS X,openSUSE等等各種的平臺的主流包管理工具。安裝方便。具體可以參照安裝文件
既然是靜態檢查工具，就一定可以整合在CI框架裡，shellcheck可以非常方便的整合在Travis CI中，供以shell指令碼爲主語言的專案進行靜態檢查。
在文件的Gallery of bad code裡，也提供了非常詳細的「壞程式碼」的標準，具有非常不錯的參考價值，可以在閒下來的時候當成」Java Puzzlers「之類的書來讀讀還是很愜意的。
不過，其實我覺得這個專案最最精華的部分都不是上面的功能，而是他提供了一個非常非常強大的wiki。在這個wiki裡，我們可以找到這個工具所有判斷的依據。在這裏，每一個檢測到的問題都可以在wiki裡找到對應的問題單號，他不僅告訴我們」這樣寫不好」，而且告訴我們」爲什麼這樣寫不好」，」我們應當怎麼寫纔好」，非常適合刨根問底黨進一步研究。
shell指令碼寫的溜，也是漲薪的必備技能哦！！如果本文對你有所幫助與借鑑，請點個在看與轉發分享支援一波哦！！
作者：Myths
鏈接：https://blog.mythsman.com/2017/07/23/1/