前言

由于工作需要，最近重新開(kāi)始拾掇shell腳本。雖然絕大部分命令自己平時(shí)也經(jīng)常使用，但是在寫(xiě)成腳本的時(shí)候總覺(jué)得寫(xiě)的很難看。而且當(dāng)我在看其他人寫(xiě)的腳本的時(shí)候，總覺(jué)得難以閱讀。畢竟shell腳本這個(gè)東西不算是正經(jīng)的編程語(yǔ)言，他更像是一個(gè)工具，用來(lái)雜糅不同的程序供我們調(diào)用。因此很多人在寫(xiě)的時(shí)候也是想到哪里寫(xiě)到哪里，基本上都像是一段超長(zhǎng)的main函數(shù)，不忍直視。同時(shí)，由于歷史原因，shell有很多不同的版本，而且也有很多有相同功能的命令需要我們進(jìn)行取舍，以至于代碼的規(guī)范很難統(tǒng)一。

考慮到上面的這些原因，我查閱了一些相關(guān)的文檔，發(fā)現(xiàn)這些問(wèn)題其實(shí)很多人都考慮過(guò)，而且也形成了一些不錯(cuò)的文章，但是還是有點(diǎn)零散。因此我就在這里把這些文章稍微整理了一下，作為以后我自己寫(xiě)腳本的技術(shù)規(guī)范。

代碼風(fēng)格規(guī)范

開(kāi)頭有“蛇棒”

所謂shebang其實(shí)就是在很多腳本的***行出現(xiàn)的以”#!”開(kāi)頭的注釋?zhuān)该髁水?dāng)我們沒(méi)有指定解釋器的時(shí)候默認(rèn)的解釋器，一般可能是下面這樣：

#!/bin/bas 

當(dāng)然，解釋器有很多種，除了bash之外，我們可以用下面的命令查看本機(jī)支持的解釋器:

#!/bin/$ cat /etc/shells  
#/etc/shells: valid login shells /bin/sh /bin/dash /bin/bash /bin/rbash /usr/bin/screen 

當(dāng)我們直接使用./a.sh來(lái)執(zhí)行這個(gè)腳本的時(shí)候，如果沒(méi)有shebang，那么它就會(huì)默認(rèn)用$SHELL指定的解釋器，否則就會(huì)用shebang指定的解釋器。

不過(guò)，上面這種寫(xiě)法可能不太具備適應(yīng)性，一般我們會(huì)用下面的方式來(lái)指定：

#!/usr/bin/env bash 

這種方式是我們推薦的使用方式。

代碼有注釋

注釋?zhuān)@然是一個(gè)常識(shí)，不過(guò)這里還是要再?gòu)?qiáng)調(diào)一下，這個(gè)在shell腳本里尤為重要。因?yàn)楹芏鄦涡械膕hell命令不是那么淺顯易懂，沒(méi)有注釋的話(huà)在維護(hù)起來(lái)會(huì)讓人尤其的頭大。

注釋的意義不僅在于解釋用途，而在于告訴我們注意事項(xiàng)，就像是一個(gè)README。

具體的來(lái)說(shuō)，對(duì)于shell腳本，注釋一般包括下面幾個(gè)部分：

• shebang
• 腳本的參數(shù)
• 腳本的用途
• 腳本的注意事項(xiàng)
• 腳本的寫(xiě)作時(shí)間，作者，版權(quán)等
• 各個(gè)函數(shù)前的說(shuō)明注釋
• 一些較復(fù)雜的單行命令注釋

參數(shù)要規(guī)范

這一點(diǎn)很重要，當(dāng)我們的腳本需要接受參數(shù)的時(shí)候，我們一定要先判斷參數(shù)是否合乎規(guī)范，并給出合適的回顯，方便使用者了解參數(shù)的使用。

最少，最少，我們至少得判斷下參數(shù)的個(gè)數(shù)吧：

if [[ $# != 2 ]];then       echo "Parameter incorrect."       exit 1    
fi 

變量和魔數(shù)

一般情況下我們會(huì)將一些重要的環(huán)境變量定義在開(kāi)頭，確保這些變量的存在。

source /etc/profileexport PATH=”/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/apps/bin/” 

這種定義方式有一個(gè)很常見(jiàn)的用途，最典型的應(yīng)用就是，當(dāng)我們本地安裝了很多java版本時(shí)，我們可能需要指定一個(gè)java來(lái)用。那么這時(shí)我們就會(huì)在腳本開(kāi)頭重新定義JAVA_HOME以及PATH變量來(lái)進(jìn)行控制。

同時(shí)，一段好的代碼通常是不會(huì)有很多硬編碼在代碼里的“魔數(shù)”的。如果一定要有，通常是用一個(gè)變量的形式定義在開(kāi)頭，然后調(diào)用的時(shí)候直接調(diào)用這個(gè)變量，這樣方便日后的修改。

縮進(jìn)有規(guī)矩

對(duì)于shell腳本，縮進(jìn)是個(gè)大問(wèn)題。因?yàn)楹芏嘈枰s進(jìn)的地方(比如if,for語(yǔ)句)都不長(zhǎng)，所有很多人都懶得去縮進(jìn)，而且很多人不習(xí)慣用函數(shù)，導(dǎo)致縮進(jìn)功能被弱化。

其實(shí)正確的縮進(jìn)是很重要的，尤其是在寫(xiě)函數(shù)的時(shí)候，否則我們?cè)陂喿x的時(shí)候很容易把函數(shù)體跟直接執(zhí)行的命令搞混。

常見(jiàn)的縮進(jìn)方法主要有”soft tab”和”hard tab”兩種。

• 所謂soft tab就是使用n個(gè)空格進(jìn)行縮進(jìn)(n通常是2或4)
• 所謂hard tab當(dāng)然就是指真實(shí)的” ”字符

這里不去撕哪種方式***，只能說(shuō)各有各的優(yōu)劣。反正我習(xí)慣用hard tab。

對(duì)于if和for語(yǔ)句之類(lèi)的，我們***不要把then，do這些關(guān)鍵字單獨(dú)寫(xiě)一行，這樣看上去比較丑。。。

命名有標(biāo)準(zhǔn)

所謂命名規(guī)范，基本包含下面這幾點(diǎn)：

• 文件名規(guī)范，以.sh結(jié)尾，方便識(shí)別
• 變量名字要有含義，不要拼錯(cuò)
• 統(tǒng)一命名風(fēng)格，寫(xiě)shell一般用小寫(xiě)字母加下劃線(xiàn)

編碼要統(tǒng)一

在寫(xiě)腳本的時(shí)候盡量使用UTF-8編碼，能夠支持中文等一些奇奇怪怪的字符。不過(guò)雖然能寫(xiě)中文，但是在寫(xiě)注釋以及打log的時(shí)候還是盡量英文，畢竟很多機(jī)器還是沒(méi)有直接支持中文的，打出來(lái)可能會(huì)有亂碼。

這里還尤其需要注意一點(diǎn)，就是當(dāng)我們是在windows下用utf-8編碼來(lái)寫(xiě)shell腳本的時(shí)候，一定要注意這個(gè)utf-8是否是有BOM的。默認(rèn)情況下windows判斷utf-8格式是通過(guò)在文件開(kāi)頭加上三個(gè)EF BB BF字節(jié)來(lái)判斷的，但是在Linux中默認(rèn)是無(wú)BOM的。因此如果我們是在windows下寫(xiě)腳本的時(shí)候，一定要注意將編碼改成Utf-8無(wú)BOM，一般用notepad++之類(lèi)的編輯器都能改。否則，在Linux下運(yùn)行的時(shí)候就會(huì)識(shí)別到開(kāi)頭的三個(gè)字符，從而報(bào)一些無(wú)法識(shí)別命令的錯(cuò)。

權(quán)限記得加

這一點(diǎn)雖然很小，但是我個(gè)人卻經(jīng)常忘記，不加執(zhí)行權(quán)限會(huì)導(dǎo)致無(wú)法直接執(zhí)行，有點(diǎn)討厭。。。

日志和回顯

日志的重要性不必多說(shuō)，能夠方便我們回頭糾錯(cuò)，在大型的項(xiàng)目里是非常重要的。

如果這個(gè)腳本是供用戶(hù)直接在命令行使用的，那么我們***還要能夠在執(zhí)行時(shí)實(shí)時(shí)回顯執(zhí)行過(guò)程，方便用戶(hù)掌控。

有時(shí)候?yàn)榱颂岣哂脩?hù)體驗(yàn)，我們會(huì)在回顯中添加一些特效，比如顏色啊，閃爍啊之類(lèi)的，具體可以參考ANSI/VT100 Control sequences這篇文章的介紹。

密碼要移除

不要把密碼硬編碼在腳本里，不要把密碼硬編碼在腳本里，不要把密碼硬編碼在腳本里。

重要的事情說(shuō)三遍，尤其是當(dāng)腳本托管在類(lèi)似Github這類(lèi)平臺(tái)中時(shí)。。。

太長(zhǎng)要分行

在調(diào)用某些程序的時(shí)候，參數(shù)可能會(huì)很長(zhǎng)，這時(shí)候?yàn)榱吮ＷC較好的閱讀體驗(yàn)，我們可以用反斜杠來(lái)分行：

./configure –prefix=/usr –sbin-path=/usr/sbin/nginx –conf-path=/etc/nginx/nginx.conf 

注意在反斜杠前有個(gè)空格。

編碼細(xì)節(jié)規(guī)范

代碼有效率

在使用命令的時(shí)候要了解命令的具體做法，尤其當(dāng)數(shù)據(jù)處理量大的時(shí)候，要時(shí)刻考慮該命令是否會(huì)影響效率。

比如下面的兩個(gè)sed命令：

./configure –prefix=/usr –sbin-path=/usr/sbin/nginx –conf-path=/etc/nginx/nginx.conf 

他們的作用一樣，都是獲取文件的***行。但是***條命令會(huì)讀取整個(gè)文件，而第二條命令只讀取***行。當(dāng)文件很大的時(shí)候，僅僅是這樣一條命令不一樣就會(huì)造成巨大的效率差異。

當(dāng)然，這里只是為了舉一個(gè)例子，這個(gè)例子真正正確的用法應(yīng)該是使用head -n1 file命令。。。

勤用雙引號(hào)

幾乎所有的大佬都推薦在使用”$”來(lái)獲取變量的時(shí)候***加上雙引號(hào)。

不加上雙引號(hào)在很多情況下都會(huì)造成很大的麻煩，為什么呢?舉一個(gè)例子：

#!/bin/sh   #已知當(dāng)前文件夾有一個(gè)a.sh的文件   var="*.sh"    
echo $var    
echo "$var" 

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

a.sh*.sh 

為啥會(huì)這樣呢?其實(shí)可以解釋為他執(zhí)行了下面的命令：

echo *.shecho "*.sh" 

在很多情況下，在將變量作為參數(shù)的時(shí)候，一定要注意上面這一點(diǎn)，仔細(xì)體會(huì)其中的差異。上面只是一個(gè)非常小的例子，實(shí)際應(yīng)用的時(shí)候由于這個(gè)細(xì)節(jié)導(dǎo)致的問(wèn)題實(shí)在是太多了。。。

巧用main函數(shù)

我們知道，像java，C這樣的編譯型語(yǔ)言都會(huì)有一個(gè)函數(shù)入口，這種結(jié)構(gòu)使得代碼可讀性很強(qiáng)，我們知道哪些直接執(zhí)行，那些是函數(shù)。但是腳本不一樣，腳本屬于解釋性語(yǔ)言，從***行直接執(zhí)行到***一行，如果在這當(dāng)中命令與函數(shù)糅雜在一起，那就非常難讀了。

用python的朋友都知道，一個(gè)合乎標(biāo)準(zhǔn)的python腳本大體上至少是這樣的：

#!/usr/bin/env python   def func1():       pass   def func2():       pass   if __name__=='__main__':       func1()       func2() 

他用一個(gè)很巧妙的方法實(shí)現(xiàn)了我們習(xí)慣的main函數(shù)，使得代碼可讀性更強(qiáng)。

在shell中，我們也有類(lèi)似的小技巧:

#!/usr/bin/env bash func1(){ #do sth } func2(){ #do sth } main(){ func1 func2 } main "$@" 

我們可以采用這種寫(xiě)法，同樣實(shí)現(xiàn)類(lèi)似的main函數(shù)，使得腳本的結(jié)構(gòu)化程度更好。

考慮作用域

shell中默認(rèn)的變量作用域都是全局的，比如下面的腳本：

#!/usr/bin/env bash var=1func(){ var=2 } func echo $var 

他的輸出結(jié)果就是2而不是1，這樣顯然不符合我們的編碼習(xí)慣，很容易造成一些問(wèn)題。

因此，相比直接使用全局變量，我們***使用local readonly這類(lèi)的命令，其次我們可以使用declare來(lái)聲明變量。這些方式都比使用全局方式定義要好。

函數(shù)返回值

在使用函數(shù)的時(shí)候一定要注意，shell中函數(shù)的返回值只能是整數(shù)，估計(jì)是因?yàn)橐话闱闆r下一個(gè)函數(shù)的返回值通常表示這個(gè)函數(shù)的運(yùn)行狀態(tài)，所以一般都是0或者是1就夠了，因此就設(shè)計(jì)成了這樣。不過(guò)，如果非得想傳遞字符串，也可以通過(guò)下面變通的方法:

func(){ echo "2333" } res=$(func) echo "This is from $res." 

這樣，通過(guò)echo或者print之類(lèi)的就可以做到傳一些額外參數(shù)的目的。

間接引用值

什么叫間接引用?比如下面這個(gè)場(chǎng)景：

VAR1="2323232" 
VAR2="VAR1" 

我們有一個(gè)變量VAR1，又有一個(gè)變量VAR2，這個(gè)VAR2的值是VAR1的名字，那么我們現(xiàn)在想通過(guò)VAR2來(lái)獲取VAR1的值，這時(shí)候應(yīng)該怎么辦呢?

比較土鱉的方法是這樣：

echo ${!VAR1} 

這個(gè)用法的確可行，但是看起來(lái)十分的不舒服，很難只管的去理解，我們并不推薦。而且事實(shí)上我們本身就不推薦使用eval這個(gè)命令。

比較舒服的寫(xiě)法是下面這樣:

echo ${!VAR1} 

通過(guò)在變量名前加一個(gè)!就可以做到簡(jiǎn)單的間接引用了。

不過(guò)需要注意的是，用上面的方法，我們只能夠做到取值，而不能做到賦值。

巧用heredocs

所謂heredocs，也可以算是一種多行輸入的方法，即在”<<”后定一個(gè)標(biāo)識(shí)符，接著我們可以輸入多行內(nèi)容，直到再次遇到標(biāo)識(shí)符為止。

使用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 

學(xué)會(huì)查路徑

很多情況下，我們會(huì)先獲取當(dāng)前腳本的路徑，然后一這個(gè)路徑為基準(zhǔn)，去找其他的路徑。通常我們是直接用pwd以期獲得腳本的路徑。

不過(guò)其實(shí)這樣是不嚴(yán)謹(jǐn)?shù)?，pwd獲得的是當(dāng)前shell的執(zhí)行路徑，而不是當(dāng)前腳本的執(zhí)行路徑。

正確的做法應(yīng)該是下面這兩種：

script_dir=$(cd $(dirname $0) && pwd)script_dir=$(dirname $(readlink -f $0 )) 

應(yīng)當(dāng)先cd進(jìn)當(dāng)前腳本的目錄然后再pwd，或者直接讀取當(dāng)前腳本的所在路徑。

代碼要簡(jiǎn)短

這里的簡(jiǎn)短不單單是指代碼長(zhǎng)度，而是只用到的命令數(shù)。原則上我們應(yīng)當(dāng)做到，能一條命令解決的問(wèn)題絕不用兩條命令解決。這不僅牽涉到代碼的可讀性，而且也關(guān)乎代碼的執(zhí)行效率。

最最經(jīng)典的例子如下：

cat /etc/passwd | grep root grep root /etc/passw 

cat命令最為人不齒的用法就是這樣，用的沒(méi)有任何意義，明明一條命令可以解決，他非得加根管道。。。

其實(shí)代碼簡(jiǎn)短在還能某種程度上能保證效率的提升，比如下面的例子：

#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后綴的文件并做一系列替換。前者是多次執(zhí)行find，后者是執(zhí)行一次find，但是增加了sed的模式串。***種可讀性更好一點(diǎn)，但是當(dāng)替換的量變大的時(shí)候，第二種的速度就會(huì)比***種快很多。這里效率提升的原因，就是第二種只要執(zhí)行一次命令，而***種要執(zhí)行多次。

命令并行化

當(dāng)我們需要充分考慮執(zhí)行效率時(shí)，我們可能需要在執(zhí)行命令的時(shí)候考慮并行化。shell中最簡(jiǎn)單的并行化是通過(guò)”&”以及”wait”命令來(lái)做:

func(){ #do sth ｝ for((i=0;i<10;i++))do func & done wait 

當(dāng)然，這里并行的次數(shù)不能太多，否則機(jī)器會(huì)卡死。稍微正確的做法比較復(fù)雜，以后再討論，如果圖省事可以使用parallel命令來(lái)做。

使用新寫(xiě)法

這里的新寫(xiě)法不是指有多厲害，而是指我們可能更希望使用較新引入的一些語(yǔ)法，更多是偏向代碼風(fēng)格的，比如

• 盡量使用func(){}來(lái)定義函數(shù)，而不是func{}
• 盡量使用[[]]來(lái)代替[]
• 盡量使用$()將命令的結(jié)果賦給變量，而不是反引號(hào)
• 在復(fù)雜的場(chǎng)景下盡量使用printf代替echo進(jìn)行回顯

事實(shí)上，這些新寫(xiě)法很多功能都比舊的寫(xiě)法要強(qiáng)大，用的時(shí)候就知道了。

其他小tip

考慮到還有很多零碎的點(diǎn)，就不一一展開(kāi)了，這里簡(jiǎn)單提一提。

• 路徑盡量保持絕對(duì)路徑，絕多路徑不容易出錯(cuò)，如果非要用相對(duì)路徑，***用./修飾
• 優(yōu)先使用bash的變量替換代替awk sed，這樣更加簡(jiǎn)短
• 簡(jiǎn)單的if盡量使用&& ||，寫(xiě)成單行。比如[[ x > 2]] && echo x
• 當(dāng)export變量時(shí)，盡量加上子腳本的namespace，保證變量不沖突
• 會(huì)使用trap捕獲信號(hào)，并在接受到終止信號(hào)時(shí)執(zhí)行一些收尾工作
• 使用mktemp生成臨時(shí)文件或文件夾
• 利用/dev/null過(guò)濾不友好的輸出信息
• 會(huì)利用命令的返回值判斷命令的執(zhí)行情況
• 使用文件前要判斷文件是否存在，否則做好異常處理
• 不要處理ls后的數(shù)據(jù)(比如ls -l | awk '{ print $8 }')，ls的結(jié)果非常不確定，并且平臺(tái)有關(guān)
• 讀取文件時(shí)不要使用for loop而要使用while read

靜態(tài)檢查工具shellcheck

概述

為了從制度上保證腳本的質(zhì)量，我們最簡(jiǎn)單的想法大概就是搞一個(gè)靜態(tài)檢查工具，通過(guò)引入工具來(lái)彌補(bǔ)開(kāi)發(fā)者可能存在的知識(shí)盲點(diǎn)。

市面上對(duì)于shell的靜態(tài)檢查工具還真不多，找來(lái)找去就找到一個(gè)叫shellcheck的工具，開(kāi)源在github上，有8K多的star，看上去還是十分靠譜的。我們可以去他的主頁(yè)了解具體的安裝和使用信息。

安裝

這個(gè)工具的對(duì)不同平臺(tái)的支持力度都很大，他至少支持了

Debian,Arch,Gentoo,EPEL,Fedora,OS X,openSUSE等等各種的平臺(tái)的主流包管理工具。安裝方便。具體可以參照安裝文檔

集成

既然是靜態(tài)檢查工具，就一定可以集成在CI框架里，shellcheck可以非常方便的集成在Travis CI中，供以shell腳本為主語(yǔ)言的項(xiàng)目進(jìn)行靜態(tài)檢查。

樣例

在文檔的Gallery of bad code里，也提供了非常詳細(xì)的“壞代碼”的標(biāo)準(zhǔn)，具有非常不錯(cuò)的參考價(jià)值，可以在閑下來(lái)的時(shí)候當(dāng)成”Java Puzzlers“之類(lèi)的書(shū)來(lái)讀讀還是很愜意的。

本質(zhì)

不過(guò)，其實(shí)我覺(jué)得這個(gè)項(xiàng)目最最精華的部分都不是上面的功能，而是他提供了一個(gè)非常非常強(qiáng)大的wiki。在這個(gè)wiki里，我們可以找到這個(gè)工具所有判斷的依據(jù)。在這里，每一個(gè)檢測(cè)到的問(wèn)題都可以在wiki里找到對(duì)應(yīng)的問(wèn)題單號(hào)，他不僅告訴我們”這樣寫(xiě)不好”，而且告訴我們”為什么這樣寫(xiě)不好”，”我們應(yīng)當(dāng)怎么寫(xiě)才好”，非常適合刨根問(wèn)底黨進(jìn)一步研究。

參考資料

• 關(guān)于 shell 腳本編程的10 個(gè)***實(shí)踐
• shell腳本編寫(xiě)規(guī)范
• Shellcheck Tool
• Best Practices for Writing Bash Scripts
• Good coding practices for bash
• Design patterns or best practices for shell scripts
• bashstyle(GITHUB)
• BashGuide/Practices
• Obsolete and deprecated syntax
• ANSI/VT100 Control sequences