1. 程式人生 > 實用技巧 >Zsh和Bash,究竟有何不同

Zsh和Bash,究竟有何不同

偶然發現這個zsh和bash的介紹文章,作者講的很基礎細節,轉載記錄學習下,也有很多其他好文章,向作者取經學習。

轉載於:破冰 https://www.xshell.net/thinking/1513.html

坑很深。

已經有不少人寫過類似“為什麼Zsh比Bash好”“為什麼Zsh比* shell好”的文章了,講解如何配置Zsh或折騰各種oh-my-zsh主題的教程也是一搜一大籮,但是卻極少看到Zsh和Bash這兩個Shell作為指令碼語言時的具體差異比較。那麼,這裡就是一篇,從語言特性的角度上簡單整理了兩者一些細微的不相容之處,供編寫可移植Shell指令碼時參考。(僅僅是從我自己過去的經驗教訓中總結出來的,所以應該也是不完全的。)

開始之前:理解Zsh的模擬模式(emulation mode)

一種流行的說法是,Zsh是與Bash相容的。這種說法既對,也不對,因為Zsh本身作為一種指令碼語言,是與Bash不相容的。符合Bash規範的指令碼無法保證被Zsh直譯器正確執行。但是,Zsh實現中包含了一個屌炸天的模擬模式(emulation mode),支援對兩種主流的Bourne衍生版shell(bash、ksh)和C shell的模擬(csh的支援並不完整)。在Bash的模擬模式下,可以使用與Bash相同的語法和命令集合,從而達到近乎完全相容的目的。為了啟用對Bash的模擬,需要顯式執行:

$ emulate bash 

等效於:

$ emulate sh 

Zsh是不會根據檔案開頭的shebang(如#!/bin/sh#!/bin/bash)自動採取相容模式來解釋指令碼的,因此,要讓Zsh解釋執行一個其他Shell的指令碼,你仍然必須手動emulate sh或者emulate ksh,告訴Zsh對何種Shell進行模擬。

那麼,Zsh究竟在何時能夠*自動*模擬某種Shell呢?

對於如今的絕大部分GNU/Linux(Debian系除外)和Mac OS X使用者來說,系統預設的/bin/sh指向的是bash

$ file /bin/sh
/bin/sh: symbolic link to `bash' 

不妨試試用zsh來取代bash

作為系統的/bin/sh

# ln -sf /bin/zsh /bin/sh 

所有的Bash指令碼仍然能夠正確執行,因為Zsh在作為/bin/sh存在時,能夠自動採取其相應的相容模式(emulate sh)來執行命令。也許正是因為這個理由,Grml直接選擇了Zsh作為它的/bin/sh,對現有的Bash指令碼能做到近乎完美的相容。

無關主題:關於/bin/sh和shebang的可移植性

說到/bin/sh,就不得不提一下,在Zsh的語境下,sh指的是大多數GNU/Linux發行版上/bin/sh預設指向的bash,或者至少是一個Bash的子集(若並非全部GNU Bash的最新特性都被實現的話),而非指POSIX shell。因此,Zsh中的emulate sh可以被用來對Bash指令碼進行模擬。

眾所周知,Debian的預設/bin/shdash(Debian Almquist shell),這是一個純粹POSIX shell相容的實現,基本上你要的bash和ksh裡的那些高階特性它都沒有。“如果你在一個#!/bin/sh指令碼中用到了非POSIX shell的東西,說明你的指令碼寫得是錯的,不關我們發行版的事情。”Debian開發者們在把預設的/bin/sh換成dash,導致一些指令碼出錯時這樣宣稱道。當然,我們應該繼續假裝與POSIX shell標準保持相容是一件重要的事情,即使現在大家都已經用上了更高階的shell。

因為有非GNU的Unix,和Debian GNU/Linux這類發行版的存在,你不能夠假設系統的/bin/sh總是GNU Bash,也不應該把#!/bin/sh用作一個Bash指令碼的shebang(——除非你願意放棄你手頭Shell的高階特性,寫只與POSIX shell相容的指令碼)。如果想要這個指令碼能夠被方便地移植的話,應指定其依賴的具體Shell直譯器:

#!/usr/bin/env bash 

這樣系統才能夠總是使用正確的Shell來執行指令碼。

(當然,顯式地呼叫bash命令來執行指令碼,shebang怎樣寫就無所謂了)


echo命令 / 字串轉義

Zsh比之於Bash,可能最容易被注意到的一點不同是,Zsh中的echoprintf是內建的命令。

$ which echo
echo: shell built-in command

$ which printf
printf: shell built-in command 

Bash中的echoprintf同樣是內建命令:

$ type echo
echo is a shell builtin

$ type printf
echo is a shell builtin 

感謝讀者提醒,在Bash中不能通過which來確定一個命令是否為外部命令,因為which本身並不是Bash中的內建命令which在Zsh中是一個內建命令。

Zsh內建的echo命令,與我們以前在GNU Bash中常見的echo命令,使用方式是*不相容*的。

首先,請看Bash:

$ echo \\
\

$ echo \\\\
\\ 

我們知道,因為這裡傳遞給echo的只是一個字串(允許使用反斜槓\轉義),所以不加引號與加上雙引號是等價的。Bash輸出了我們預想中的結果:每兩個連續的\轉義成一個\字元輸出,最終2個變1個,4個變2個。沒有任何驚奇之處。

你能猜到Zsh的輸出結果麼?










$ echo \\
\

$ echo \\\\
\ 

(゜Д゜*)

解釋稍後。

我們還知道,要想避免一個字串被反斜槓轉義,可以把它放進單引號。正如我們在Bash中所清楚看到的這樣,所有的反斜槓都照原樣輸出:

$ echo '\\'
\\

$ echo '\\\\'
\\\\ 

再一次,你能猜到Zsh的輸出結果麼?










$ echo '\\'
\

$ echo '\\\\'
\\ 

((((((゜Д゜*))))))))))))

這個解釋是這樣的:在前一種不加引號(或者加了雙引號)的情形下,傳遞給echo內部命令的字串將首先被轉義,echo \\中的\\被轉義成\echo \\\\中的\\\\被轉義成\\。然後,在echo這個內部命令輸出到終端的時候,它還要把這個東西再轉義一遍,一個單獨的\沒法轉義,所以仍然是作為\輸出;連續的\\被轉義成\,所以輸出就是\。因此,echo \\echo \\\\的輸出相同,都是\

為了讓Zsh中echo的輸出不被轉義,需要顯式地指明-E選項:

$ echo -E \\
\

$ echo -E \\\\
\\ 

於是,我們也就知道在後一種加單引號的情形下,如何得到與原字串完全相同的輸出了:

$ echo -E '\\'
\\

$ echo -E '\\\\'
\\\\ 

而Bash的echo預設就是不對輸出進行轉義的,若要得到轉義的效果,需顯式地指定-e選項。Bash和Zsh中echo命令用法的不相容,在這裡體現出來了。

變數的自動分字(word splitting)

在Bash中,你可以通過呼叫外部命令echo輸出一個字串:

echo $text 

我們知道,Bash會對傳遞給命令的字串進行分字(根據空格或換行符),然後作為多個引數傳給echo。當然,作為分隔符的換行,在最終輸出時就被抹掉了。於是,更好的習慣是把變數名放在雙引號中,把它作為一個字串傳遞,這樣就可以保留文字中的換行符,將其原樣輸出。

echo "$text" 

在Zsh中,你不需要通過雙引號來告訴直譯器“$text是一個字串”。直譯器不會把它轉換成一個由空格或者\n分隔的引數列表或者別的什麼。所以,沒有Bash中的trick,直接echo $text就可以保留換行符。但是,如前一節所說,我們需要一個多餘的工作來保證輸出的是未轉義的原始文字,那就是-E選項:

echo -E $text 

從這裡我們看到,Zsh中的變數在傳遞給命令時是不會被自動切分成words然後以多個引數的形式存在的。它仍然保持為一個量。這是它與傳統的Bourne衍生shell(ksh、bash)的一個重要不相容之處。這是Zsh的特性,而不是一個bug

萬用字元展開(globbing)

萬用字元展開(globbing)也許是Unix shell中最為實用化的功能之一。比起正則表示式,它的功能相當有限,不過它的確能滿足大部分時候的需求:依據固定的字首或字尾匹配檔案。需要更復雜模式的時候其實是很少見的,至少在檔案的命名和查詢上。

Bash和Zsh對萬用字元展開的處理方式有何不同呢?舉個例子,假如我們想要列舉出當前目錄下所有的.markdown檔案,但實際上又不存在這樣的檔案。在Zsh中:(注意到這裡使用了內建的echo,因為我們暫時還不想用到外部的系統命令)

$ echo *.markdown
zsh: no matches found: *.markdown 

Bash中:

$ echo *.markdown
*.markdown 

Zsh因為萬用字元展開失敗而報錯;而Bash在萬用字元展開失敗時,會放棄把它作為萬用字元展開、直接把它當做字面量返回。看起來,Zsh的處理方式更優雅,因為這樣你就可以知道這個萬用字元確實無法展開;而在Bash中,你很難知道究竟是不存在這樣的檔案,還是存在一個檔名為'*.markdown'的檔案。

接下來就是不那麼和諧的方面了。

在Zsh中,用ls檢視當然還是報錯:

$ ls *.markdown
zsh: no matches found: *.markdown 

Bash,這時候呼叫ls也會報錯。因為當前目錄下沒有.markdown字尾的檔案,萬用字元展開失敗後變成字面的'*.markdown',這個檔案自然也不可能存在,所以外部命令ls報錯:

$ ls *.markdown
ls: cannot access *.markdown: No such file or directory 

同樣是錯誤,差別在哪裡?對於Zsh,這是一個語言級別的錯誤;對於Bash,這是一個外部命令執行的錯誤。這件差別很重要,因為它意味著後者可以被輕易地catch,而前者不能。

想象一個常見的指令式程式設計語言,Java或者Python。你可以用try...catch或類似的語言結構來捕獲執行時的異常,比較優雅地處理無法預料的錯誤。Shell當然沒有通用的異常機制,但是,你可以通過檢測某一段命令的返回值來模擬捕獲執行時的錯誤。例如,在Bash裡可以這樣:

$ if ls *.markdown &>/dev/null; then :; else echo $?; fi
2 

於是,在萬用字元展開失敗的情形下,我們也能輕易地把外部命令的錯誤輸出重定向到/dev/null,然後根據返回的錯誤碼執行後續的操作。

不過在Zsh中,這個來自Zsh直譯器自身的錯誤輸出卻無法被重定向:

$ if ls *.markdown &>/dev/null; then :; else echo $?; fi
zsh: no matches found: *.markdown
1 

大部分時候,我們並不想看到這些醜陋多餘的錯誤輸出,我們期望程式能完全捕獲這些錯誤,然後完成它該完成的工作。但這也許是一種正常的行為。理由是,在程式語言裡,syntax error一般是無法簡單地由使用者在執行階段自行catch的,這個報錯工作將直接由直譯器來完成。除非,當然,除非我們用了邪惡的eval

$ if eval "ls *.markdown" &>/dev/null; then :; else echo $?; fi
1 

Eval is evil. 但在Zsh中捕獲這樣的錯誤,似乎沒有更好的辦法了。必須這麼做的原因就是:Zsh中,萬用字元展開失敗是一個語法錯誤。而在Bash中則不是。

基於上述理由,依賴於Bash中萬用字元匹配失敗而直接把"*"當作字面量傳遞給命令的寫法,在Zsh中是無法正常執行的。例如,在Bash中你可以:(雖然在大部分情況下*能用*,但顯然不加引號是不科學的)

$ find /usr/share/git -name *.el 

因為Zsh不會在glob擴充套件失敗後自動把"*"當成字面量,而是直接報錯終止執行,所以在Zsh中你必須"*.el"加上引號,來避免這種擴充套件:

$ find /usr/share/git -name "*.el" 

字串比較

在Bash中判斷兩個字串是否相等:

[ "$foo" = "$bar" ] 

或與之等效的(現代程式語言中更常見的==比較運算子):

[ "$foo" == "$bar" ] 

注意等號左右必須加空格,變數名一定要放在雙引號中。(寫過Shell的都知道這些規則的重要性)

在條件判斷的語法上,Zsh基本和Bash相同,沒有什麼改進。除了它的直譯器想得太多,以至於不小心把==當做了一個別的東西:

$ [ foo == bar ]; echo $?
zsh: = not found 

要想使用我們最喜歡的==,只有把它用引號給保護起來,不讓直譯器做多餘的解析:

$ [ foo "==" bar ]; echo $?
1 

所以,為了少打幾個字元,還是老老實實用更省事的=吧。

陣列

同樣用一個簡單的例子來說明。Bash:

array=(alpha bravo charlie delta) echo $array echo ${array[*]} echo ${#array[*]} for ((i=0; i < ${#array[*]}; i++)); do  echo ${array[$i]} done 

輸出:

alpha
alpha bravo charlie delta
4
alpha
bravo
charlie
delta 

很容易看到,Bash的陣列下標是從0開始的$array取得的實際上是陣列的第一個元素的值,也就是${array[0]}(這些行為和C有點像)。要想取得整個陣列的值,必須使用${array[*]}${array[@]},因此,獲取陣列的長度可以使用${#array[*]}。在Bash中,必須記得在訪問陣列元素時給整個陣列名連同下標加上花括號,比如,${array[*]}不能寫成$array[*],否則直譯器會首先把$array當作一個變數來處理。

再來看這段Zsh:

array=(alpha bravo charlie delta) echo $array echo $array[*] echo $#array for ((i=1; i <= $#array[*]; i++)); do  echo $array[$i] done 

輸出:

alpha bravo charlie delta
alpha bravo charlie delta
4
alpha
bravo
charlie
delta 

在Zsh中,$array$array[*]一樣,可以用來取得整個陣列的值。因此獲取陣列的長度可直接用$#array

Zsh的預設陣列下標是從1而不是0開始的,這點更像C shell。(雖然一直無法理解一個名字叫C的shell為何會採用1作為陣列下標開始這種奇葩設定)

最後,Zsh不需要藉助花括號來訪問陣列元素,因此Bash中必需的花括號都被略去了。

關聯陣列

Bash 4.0+和Zsh中都提供了對類似AWK關聯陣列的支援。

declare -A array
array[mort]=foo 

和普通的陣列一樣,在Bash中,必須顯式地藉助花括號來訪問一個數組元素:

echo ${array[mort]} 

而Zsh中則沒有必要:

echo $array[mort] 

說到這裡,我們注意到Zsh有一個不同尋常的特性:支援使用方括號進行更復雜的globbingarray[mort]這樣的寫法事實上會造成二義性:究竟是取array這個關聯陣列以mort為key的元素值呢,還是以萬用字元展開的方式匹配當前目錄下以"array"開頭,以"m""o""r""t"任一字元結尾的檔名呢?

array[mort]=作為命令開始的情況下,不存在歧義,這是一個對關聯陣列的賦值操作。在前面帶有$的情況下,Zsh會自動把$array[mort]識別成取關聯陣列的值,這也沒有太大問題。問題出在它存在於命令中間,卻又不帶$的情況,比如:

read -r -d '' array[mort] << 'EOF' hello world EOF 

我們的本意是把這個heredoc賦值給array[mort]陣列元素。在Bash中,這是完全合法的。然而,在Zsh中,直譯器會首先試圖對"array[mort]"這個模式進行glob展開,如果當前目錄下沒有符合該模式的檔案,當然就會報出一個語法錯誤:

zsh: no matches found: array[mort] 

這是一件很傻的事情,為了讓這段指令碼能夠被Zsh直譯器正確執行,我們需要把array[mort]放在引號中以防止被展開:

read -r -d '' 'array[mort]' << 'EOF' hello world EOF 

這是Zsh在擴充套件了一些強大功能的同時帶來的不便之處(或者說破壞了現有指令碼相容性的安全隱患,又或者是讓直譯器混亂的pitfalls)。

順便說一句,用Rake構建過專案的Rails程式設計師都知道,有些時候需要在命令列下通過方括號給rake傳遞引數值,如:

$ rake seeder:seed[100] 

Zsh這個對方括號展開的特性確實很不方便。如果不想每次都用單引號把引數括起來,可以完全禁止Zsh對某條命令後面的引數進行glob擴充套件:(~/.zshrc

alias rake="noglob rake" 

嗯,對於rake命令來說,glob擴充套件基本是沒有用的。你可以關掉它。

分號與空語句

雖然有點無聊,但還是想提一下:Bash不允許語句塊中使用空語句,最小化的語句是一個noop命令(:);而Zsh允許空語句

剛開始寫Bash的時候,總是記不得什麼時候該加分號什麼時候不該加。比如

if [ 1 ] then : fi 

如果放在一行裡寫,應該是

if [ 1 ]; then :; fi 

then後面是不能接分號的,如果寫成

if [ 1 ]; then; :; fi 

就會報錯:

bash: syntax error near unexpected token `;' 

解釋是:then表示一個程式碼段的開始,fi表示結束,這中間的內容必須是若干行命令,或者以分號;結尾的放在同一行內的多條命令。我們知道在傳統的shell中,分號本身並不是一條命令,空字串也不是一條命令,因此,then後面緊接著的分號就會帶來一條語法錯誤。(有些時候對某個“語言特性”的所謂解釋只是為了掩飾設計者在一開始犯的錯誤,所以就此打住)

在Zsh中,上述兩種寫法都合法。因為它允許只包含一個分號的空命令。

$ ; 

當然,因為分號只是一個語句分隔符,所以沒有也是可以的。這種寫法在Zsh中合法:(then的語句塊為空)

if [ 1 ]; then fi