程序員必備神器！Shell 腳本編程最佳實踐

做者：Myths
連接：https://blog.mythsman.com/201...

前言

因爲工做須要，最近從新開始拾掇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"

在不少狀況下，在將變量做爲參數的時候，必定要注意上面這一點，仔細體會其中的差別。上面只是一個很是小的例子，實際應用的時候因爲這個細節致使的問題實在是太多了。。。

巧用main函數

咱們知道，像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，也能夠算是一種多行輸入的方法，即在」<<」後定一個標識符，接着咱們能夠輸入多行內容，直到再次遇到標識符爲止。

使用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進行回顯

事實上，這些新寫法不少功能都比舊的寫法要強大，用的時候就知道了。

其餘小tip

考慮到還有不少零碎的點，就不一一展開了，這裏簡單提一提。

路徑儘可能保持絕對路徑，絕多路徑不容易出錯，若是非要用相對路徑，最好用./修飾

優先使用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命令複製文件夾的時候要注意若是目的文件夾不存在則會建立，若是存在則會複製到該文件的子文件夾下

靜態檢查工具shellcheck

概述

爲了從制度上保證腳本的質量，咱們最簡單的想法大概就是搞一個靜態檢查工具，經過引入工具來彌補開發者可能存在的知識盲點。

市面上對於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腳本寫的溜，也是漲薪的必備技能哦！！若是本文對你有所幫助與借鑑，請點個在看與轉發分享支持一波哦！！