作為一枚Linux嵌入式程序猿,寫shell腳本也是經(jīng)常碰到的工作,在這個(gè)過(guò)程中或多或少踩過(guò)一些坑,也積累了一些經(jīng)驗(yàn),在此分享給大家,希望能對(duì)大家有點(diǎn)幫助。
1. 指定bash
我們知道在shell 腳本的第一行,都應(yīng)該指定bash,那#!之后到底應(yīng)該是什么呢?
這個(gè)問(wèn)題估計(jì)不同的人的回答可能都不一樣。我見(jiàn)過(guò)/usr/bin/env bash,也見(jiàn)過(guò)/bin/bash,還有/usr/bin/bash,還有/bin/sh,還有/usr/bin/env sh。我自己也用過(guò)其中過(guò)的幾個(gè),其實(shí)在很多情況下,以上幾種寫法效果都是相同的。但是,坑我們的往往就是少數(shù)情況~
如果恰好碰到系統(tǒng)的默認(rèn)shell不是bash怎么辦?比如某Linux發(fā)行版的某個(gè)版本,默認(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這個(gè)腳本不存在的情況下,source不成功,不會(huì)運(yùn)行source后面的代碼。
而在#!/bin/bash的情況下,雖然source不成功,但是還是運(yùn)行了source后面的echo語(yǔ)句。
為什么會(huì)這樣呢?
接下來(lái)我們看一看/bin/sh是個(gè)什么東西。
從上面可以看到,sh只是bash的一個(gè)軟鏈接,在一般的linux系統(tǒng)當(dāng)中,sh調(diào)用執(zhí)行腳本相當(dāng)于打開(kāi)了bash的posix模式,也就是說(shuō) /bin/sh 相當(dāng)于 /bin/bash --posix。posix的特定規(guī)范之一是,當(dāng)某行代碼出錯(cuò)時(shí),便不繼續(xù)往下解釋。
把腳本改成如下圖所示的格式,我們得到運(yùn)行結(jié)果和#!/bin/sh是一樣的。
#!/bin/bash --posix
source mlryj.sh
echo “hello world!”
推薦大家使用 /usr/bin/env bash 和 /bin/bash。前者通過(guò)env添加一個(gè)中間層,讓env在PATH中搜索bash;后者畢竟是有官方背書的,約定俗成的bash位置。但是當(dāng)腳本出現(xiàn)了錯(cuò)誤怎么辦呢?請(qǐng)看Tip2。
2. set -e 和 set -x
好了,關(guān)于指定bash已經(jīng)完成了。接下來(lái)該開(kāi)始寫shell腳本第二行、第三行。
小編建議:在你開(kāi)始構(gòu)思并寫下具體的代碼邏輯之前,先插入一行“set -e”和一行“set -x”。
set -x會(huì)在執(zhí)行每一行shell腳本時(shí),把執(zhí)行的內(nèi)容輸出來(lái)。它可以讓你看到當(dāng)前執(zhí)行的情況,里面涉及的變量也會(huì)被替換成實(shí)際的值。
set -e會(huì)在執(zhí)行出錯(cuò)時(shí)結(jié)束程序,就像其他語(yǔ)言中的“拋出異?!币粯印?/p>
這兩個(gè)組合在一起,可以在debug的時(shí)候替自己節(jié)省許多時(shí)間。出于防御性編程的考慮,有必要在寫第一行具體的代碼之前就插入它們。捫心自問(wèn),寫代碼的時(shí)候能夠一次寫對(duì)的次數(shù)有多少?大多數(shù)代碼,在提交之前,通常都經(jīng)歷過(guò)反復(fù)調(diào)試修改的過(guò)程。與其在焦頭爛額之際才引入這兩個(gè)配置,不如一開(kāi)始就給調(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開(kāi)始的三行代碼,但是具體的業(yè)務(wù)邏輯一行都沒(méi)寫。是不是該開(kāi)始寫了?
且慢!工欲善其事,必先利其器。小編先給各位介紹一個(gè)shell腳本編寫神器:shellcheck
很慚愧,雖然這幾年寫了一些shell腳本,但是真正寫起來(lái)的時(shí)候還是有很多語(yǔ)法記不清楚。這時(shí)候就要依仗shellcheck了。
shellcheck除了可以提醒語(yǔ)法問(wèn)題以外,還能檢查出shell腳本編寫常見(jiàn)的錯(cuò)誤代碼。相信我,使用shellcheck會(huì)給我們的shell編寫能力帶來(lái)了巨大的飛躍的。
安裝方法如下圖:
安裝完成后可以通過(guò)shellcheck -V查看當(dāng)前安裝成功的版本號(hào)。如下圖:
雖然我們技能不如別人,但是我們可以升級(jí)裝備,在裝備上趕上并超過(guò)對(duì)方??!有了shellcheck加持就好比真三中諸葛亮帶上了飛鞋,郭嘉買了孫子兵法,哈哈哈~~
4. 注意local
首先我們來(lái)看一下下面兩段代碼及運(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并沒(méi)有輸出變量a的內(nèi)容。
這是因?yàn)樵赽ash,如果不加local限定詞,變量默認(rèn)都是全局的。在頂級(jí)作用域里,是否是全局變量并不重要。但是在函數(shù)里面,聲明一個(gè)全局變量可能會(huì)污染到其他作用域,尤其在你根本沒(méi)有注意到這一點(diǎn)的情況下。當(dāng)我們開(kāi)始把重復(fù)的邏輯提煉成函數(shù),這時(shí)就有可能會(huì)掉到bash的這一個(gè)坑里。所以,對(duì)于在函數(shù)內(nèi)聲明的變量,小編的建議是記得加上local限定詞。
5. 寫在最后
以上幾條都是具體的建議,這條來(lái)點(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之類的語(yǔ)言編寫腳本。
程序猿無(wú)論寫什么代碼,都要三思而行,切忌粗心大意。畢竟許多時(shí)候,我們的一個(gè)粗心就會(huì)給整個(gè)系統(tǒng)帶來(lái)一個(gè)悲劇,其實(shí)復(fù)雜的腳本也是發(fā)端于幾行小小的命令。一開(kāi)始寫腳本的人,也許以為它只是一次性任務(wù)。代碼里難免對(duì)一些外部條件有些假定,在當(dāng)時(shí)也許是正常的,但是隨著外部環(huán)境的變化,這些就成了隱藏的雷。這就需要在編寫的時(shí)候辨清哪些是會(huì)變的依賴、哪些是腳本正常運(yùn)行所不可或缺的。同時(shí)要有防御性編程的意識(shí),給自己的代碼一道護(hù)城河。
-
Linux
+關(guān)注
關(guān)注
87文章
11171瀏覽量
208474 -
Shell
+關(guān)注
關(guān)注
1文章
361瀏覽量
23234
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論