linux中Shell腳本編程陷阱有哪些

這篇文章給大家分享的是有關(guān)linux中Shell腳本編程陷阱有哪些的內(nèi)容。小編覺得挺實(shí)用的，因此分享給大家做個(gè)參考，一起跟隨小編過來看看吧。

Shell 腳本很棒，你可以非常輕松地寫出有用的東西來。甚至像是下面這個(gè)傻瓜式的命令：

# 用含有 Go 的詞匯起名字：$ grep -i ^go /usr/share/dict/* | cut -d: -f2 | sort -R | head -n1goldfish

如果用其他編程語言，就需要花費(fèi)更多的腦力，用多行代碼實(shí)現(xiàn)，比如用 Ruby 的話：

puts(Dir['/usr/share/dict/*-english'].map do |f|  File.open(f)    .readlines    .select { |l| l[0..1].downcase == 'go' }end.flatten.sample.chomp)

Ruby 版本的代碼雖然不是那么長(zhǎng)，也并不復(fù)雜。但是 shell 版是如此簡(jiǎn)單，我甚至不用實(shí)際測(cè)試就可以確保它是正確的。而 Ruby 版的我就沒法確定它不會(huì)出錯(cuò)了，必須得測(cè)試一下。而且它要長(zhǎng)一倍，看起來也更復(fù)雜。

這就是人們使用 Shell 腳本的原因，它簡(jiǎn)單卻實(shí)用。下面是另一個(gè)例子：

curl https://nl.wikipedia.org/wiki/Lijst_van_Nederlandse_gemeenten |    grep '^<li><a href=' |    sed -r 's|<li><a href="/wiki/.+" title=".+">(.+)</a>.*</li>|\1|' |    grep -Ev '(^Tabel van|^Lijst van|Nederland)'

這個(gè)腳本可以從維基百科上獲取荷蘭基層政權(quán)的列表。幾年前我寫了這個(gè)臨時(shí)的腳本，用來快速生成一個(gè)數(shù)據(jù)庫，到現(xiàn)在它仍然可以正常運(yùn)行，當(dāng)時(shí)寫它并沒有花費(fèi)我多少精力。但要用 Ruby 完成同樣的功能則會(huì)麻煩得多。

現(xiàn)在來說說 shell 的缺點(diǎn)吧。隨著代碼量的增加，你的腳本會(huì)變得越來越難以維護(hù)，但你也不會(huì)想用別的語言重寫一遍，因?yàn)槟阋呀?jīng)在這個(gè) shell 版上花費(fèi)了很多時(shí)間。

我把這種情況稱為“Shell 腳本編程陷阱”，這是沉沒成本謬論的一種特例（LCTT 譯注：“沉沒成本謬論”是一個(gè)經(jīng)濟(jì)學(xué)概念，可以簡(jiǎn)單理解為，對(duì)已經(jīng)投入的成本可能被浪費(fèi)而念念不忘）。

實(shí)際上許多腳本會(huì)增長(zhǎng)到超出預(yù)期的大小，你經(jīng)常會(huì)花費(fèi)過多的時(shí)間來“修復(fù)某個(gè) bug”，或者“添加一個(gè)小功能”。如此循環(huán)往復(fù)，讓人頭大。

如果你從一開始就使用 Python、Ruby 或是其他類似的語言來寫這個(gè)程序，你可能會(huì)在寫***版的時(shí)候多花些時(shí)間，但以后維護(hù)起來就容易很多，bug 也肯定會(huì)少很多。

以我的 packman.vim 腳本為例。它起初只包含一個(gè)簡(jiǎn)單的用來遍歷所有目錄的 for 循環(huán)，外加一個(gè) git pull，但在這之后就剎不住車了，它現(xiàn)在有  200 行左右的代碼，這肯定不能算是最復(fù)雜的腳本，但假如我一上來就按計(jì)劃用 Go  來編寫它的話，那么增加一些像“打印狀態(tài)”或者“從配置文件里克隆新的 git  庫”這樣的功能就會(huì)輕松很多；添加“并行克隆”的支持也幾乎不算個(gè)事兒了，而在 shell  腳本里卻很難實(shí)現(xiàn)（盡管不是不可能）。事后看來，我本可以節(jié)省時(shí)間，并且獲得更好的結(jié)果。

出于類似的原因，我很后悔寫出了許多這樣的 shell 腳本，而我在 2018 年的新年誓言就是不要再犯類似的錯(cuò)誤了。

附錄：?jiǎn)栴}匯總

需要指出的是，shell 編程的確存在一些實(shí)際的限制。下面是一些例子：

• 在處理一些包含“空格”或者其他“特殊”字符的文件名時(shí)，需要特別注意細(xì)節(jié)。絕大多數(shù)腳本都會(huì)犯錯(cuò)，即使是那些經(jīng)驗(yàn)豐富的作者（比如我）編寫的腳本，因?yàn)樘菀讓戝e(cuò)了，只添加引號(hào)是不夠的。

• 有許多所謂“正確”和“錯(cuò)誤”的做法。你應(yīng)該用 which 還是 command？該用 $@ 還是 $*，是不是得加引號(hào)？你是該用 cmd $arg 還是 cmd "$arg"？等等等等。

• 你沒法在變量里存儲(chǔ)空字節(jié)（0x00）；shell 腳本處理二進(jìn)制數(shù)據(jù)很麻煩。

• 雖然你可以非?？焖俚貙懗鲇杏玫臇|西，但實(shí)現(xiàn)更復(fù)雜的算法則要痛苦許多，即使用 ksh/zsh/bash 擴(kuò)展也是如此。我上面那個(gè)解析 HTML 的腳本臨時(shí)用用是可以的，但你真的不會(huì)想在生產(chǎn)環(huán)境中使用這種腳本。

• 很難寫出跨平臺(tái)的通用型 shell 腳本。/bin/sh 可能是 dash 或者 bash，不同的 shell 有不同的運(yùn)行方式。外部工具如 grep、sed 等，不一定能支持同樣的參數(shù)。你能確定你的腳本可以適用于 Linux、macOS 和 Windows 的所有版本嗎（無論是過去、現(xiàn)在還是將來）？

• 調(diào)試 shell 腳本會(huì)很難，特別是你眼中的語法可能會(huì)很快變得記不清了，并不是所有人都熟悉 shell 編程的語境。

• 處理錯(cuò)誤會(huì)很棘手（檢查 $? 或是 set -e），排查一些超過“出了個(gè)小錯(cuò)”級(jí)別的復(fù)雜錯(cuò)誤幾乎是不可能的。

• 除非你使用了 set -u，變量未定義將不會(huì)報(bào)錯(cuò)，而這會(huì)導(dǎo)致一些“搞笑事件”，比如 rm -r ~/$undefined 會(huì)刪除用戶的整個(gè)家目錄（瞅瞅 Github 上的這個(gè)悲?。?。

• 所有東西都是字符串。一些 shell 引入了數(shù)組，能用，但是語法非常丑陋和費(fèi)解。帶分?jǐn)?shù)的數(shù)字運(yùn)算仍然難以應(yīng)付，并且依賴像 bc 或 dc 這樣的外部工具（$(( .. )) 這種方式只能對(duì)付一下整數(shù)）。

感謝各位的閱讀！關(guān)于“l(fā)inux中Shell腳本編程陷阱有哪些”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，讓大家可以學(xué)到更多知識(shí)，如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到吧！