補充shell的一些容易搞錯的地方代碼執(zhí)行是不是都要經(jīng)過shell不是。程序代碼執(zhí)行完全可以不經(jīng)過 shell。shell 只是一個 “用來啟動別的程序” 的工具不是所有程序運行的必經(jīng)層。下面把兩種路徑拆開講結合你編譯、make、buildroot 的場景。1. 兩條完全不同的執(zhí)行路徑路徑 A經(jīng)過 shell你敲命令、shell 腳本gcc test.c你在 bashshell這個進程里輸入命令bash 解析字符串分詞、通配符*.c、變量替換$VAR、管道、重定向 out.txtbash 調用fork()創(chuàng)建子進程然后在子進程里調用exec()加載gcc程序gcc 開始運行。 這里 shell 的工作解析命令字符串然后啟動目標程序。gcc 本身的代碼運行一旦 exec 成功就和 shell 沒關系了只是父子進程關系。路徑 B不經(jīng)過 shell直接 execC 代碼、make 內部調用、很多底層腳本C 語言里// 直接啟動 gcc不經(jīng)過任何shell char *argv[] {gcc, test.c, -o, test, NULL}; execvp(gcc, argv);流程當前進程直接execvp傳入程序名 參數(shù)數(shù)組內核加載 gcc直接跑沒有 shell 參與不會做通配符、變量替換、管道解析。make 在執(zhí)行 Makefile 命令時默認行為如果命令行里沒有特殊 shell 元字符$ | * ;等make 會嘗試直接exec不啟動 shell如果檢測到元字符make 才會啟動/bin/sh把命令交給 shell 解析。2. fork /exec 核心模型重點Linux 啟動新程序底層永遠是fork()→ 創(chuàng)建子進程復制環(huán)境變量、內存exec()→ 在子進程里把原有程序替換成新程序gcc/make/ 你的程序fork/exec 是系統(tǒng)調用屬于內核不是 shell 提供的shell 只是調用 forkexec 的眾多程序之一。任何 C/Python/go 程序都可以直接調用 forkexec不需要 shell。3. 幾個容易混淆的場景? 場景 1運行編譯出來的二進制程序./a.out你在終端敲./a.out由 shell 解析這個命令字符串forkexec 啟動 a.outa.out 運行時它自己的代碼執(zhí)行完全不需要 shellshell 只負責把它啟動起來。a.out 跑起來之后shell 只是父進程等待它退出wait。a.out 內部邏輯和 shell 無關。? 場景 2make 執(zhí)行 Makefile 里的命令all: gcc test.cmake 本身是一個獨立二進制程序。make 讀到gcc test.c判斷有沒有 shell 特殊符號沒有就直接 exec gcc不啟動 shell。如果寫成gcc test.c log.txt里面有make 會調用/bin/sh -c gcc test.c log.txt此時會啟動 shell來處理重定向。? 場景 3shell 腳本xxx.sh腳本里每一行命令gcc test.cshellbash讀到這一行forkexec gcc這里有 shell 參與啟動 gcc。? 場景 4Python / Go 代碼啟動程序import subprocess subprocess.run([gcc, test.c]) # 列表形式直接exec不啟動shell subprocess.run(gcc test.c, shellTrue) # 字符串形式啟動shell去解析這就是為什么 Python subprocess 推薦傳列表避免 shell 注入也少一層開銷。4. 環(huán)境變量傳遞兩種方式都能傳不管有沒有 shell 參與啟動進程fork 的時候子進程都會復制父進程的環(huán)境變量。父進程是 bashfork 出來的子進程繼承 bash 環(huán)境父進程是 makefork 出來的子進程繼承 make 進程環(huán)境父進程是 gccgcc 再 fork 子進程子進程繼承 gcc 環(huán)境環(huán)境變量的傳遞是 fork 系統(tǒng)調用自帶的能力和 shell 無關。shell 只是幫你方便設置環(huán)境變量它不是環(huán)境變量傳遞的必要條件。5. 關鍵區(qū)分「啟動程序」 vs 「程序運行」shell 負責解析命令字符串、通配符、變量替換、管道重定向可選環(huán)節(jié)可以跳過內核負責fork 創(chuàng)建子進程、exec 加載二進制、傳遞環(huán)境變量必須環(huán)節(jié)二進制程序gcc/make/a.out加載后CPU 直接跑機器碼完全不需要 shell 在場6. 結合你 buildroot 的場景總結buildroot 是一堆 Makefile shell 腳本混合。buildroot 腳本里很多命令是 shell 去啟動 make、gccmake 內部很多編譯命令直接 exec gcc不再額外嵌套 shellgcc 編譯源代碼生成目標文件整個編譯過程gcc 本身運行不需要 shellshell 只出現(xiàn)在解析腳本字符串、處理重定向 / 管道這些需要文本解析的地方。7. 一個簡單記憶口訣shell 是 “命令翻譯器 啟動器”不是程序運行的虛擬機。程序跑起來不需要 shell只有當你需要解析命令字符串的時候才需要 shell。shell腳本本質是不是就是shell命令行的集合大體可以這么理解但不完全準確shell 腳本 寫在文件里、按順序執(zhí)行的 shell 代碼不只是簡單 “命令行復制粘貼集合”。1. 相似點你直覺里的那部分你在終端手動敲的每一行 bash 命令絕大多數(shù)直接復制進.sh文件就能跑。# test.sh pwd echo hello export CFLAGS-O2 lsbash test.sh就會依次執(zhí)行這幾行就像你一行一行手動敲。從這個角度腳本就是把一堆命令行保存成文件批量自動執(zhí)行。2. 但是腳本 ≠ 單純命令行集合有幾個關鍵區(qū)別區(qū)別 1默認是新進程執(zhí)行最關鍵和環(huán)境變量強相關你在終端敲命令在當前交互式 shell 進程執(zhí)行bash test.sh會新建一個子 shell 進程來執(zhí)行腳本里所有代碼。腳本里面export的變量只在這個子進程里面腳本跑完就消失不會污染你外面終端的環(huán)境。這就是前面講的環(huán)境變量作用范圍而source test.sh才是不新建進程直接在當前交互式 shell 里面跑腳本里的代碼和手動敲完全一樣。區(qū)別 2腳本有語法能力交互式命令行也能用但腳本更適合寫復雜邏輯shell 不只是只能跑命令它是一門完整編程語言分支if ... then ... else循環(huán)for / while函數(shù)、變量、數(shù)組、比較判斷這些代碼交互式終端也可以一行一行敲但寫在文件里維護更方便。# 腳本里可以寫這種邏輯終端也能敲但是寫文件里方便復用 for file in *.c; do echo $file done所以shell 既是交互式命令解釋器你敲命令的終端又是腳本編程語言解釋器讀 sh 文件執(zhí)行同一個程序bash干兩件事。區(qū)別 3解析規(guī)則細節(jié)有差異交互 shell vs 非交互 shellbash 分兩種模式交互式 shell你打開終端有提示符$可以手動輸入會加載~/.bashrc非交互式 shellbash test.sh跑腳本不會加載.bashrc啟動環(huán)境不一樣。 所以有些命令在終端直接跑正常放到腳本里跑就環(huán)境不一樣PATH、變量不一樣這是嵌入式 /buildroot 腳本非常常見的坑。區(qū)別 4腳本默認有參數(shù)$1,$2,$可以接收外部傳入?yún)?shù)# test.sh echo 第一個參數(shù)$1執(zhí)行bash test.sh abc腳本拿到abc參數(shù)。交互式命令行也能寫但腳本把參數(shù)傳遞封裝得更常用。3. 澄清一個容易混淆的點shell 腳本里面不全是外部命令pwd、ls、gcc一部分是 shell內置命令export、cd、if、echo不需要 fork 新進程shell 自己直接執(zhí)行。另一部分是外部二進制程序ls、pwd、make需要 forkexec 啟動子進程。4. 極簡總結?簡單腳本就是一堆命令行寫到文件批量執(zhí)行?但不只是命令的簡單集合它可以帶分支循環(huán)、函數(shù)并且默認跑在獨立子進程環(huán)境隔離底層bash 程序是同一個只是運行模式不同交互模式終端 / 非交互模式執(zhí)行腳本文件。5. 聯(lián)系你前面的知識點手動終端敲當前 shell 進程export 變量保留在終端bash xxx.sh新建子 shell 進程腳本內修改環(huán)境變量腳本結束全部消失source xxx.sh在當前 shell 執(zhí)行腳本代碼等價于你手動一行一行敲命令變量保留在當前終端。要不要我舉個小例子對比bash test.sh和source test.sh直觀看到環(huán)境變量的差別為啥默認要創(chuàng)建子進程去跑腳本然后又要設置source允許在當前環(huán)境跑默認開子進程跑腳本是安全隔離source 是專門用來打破隔離的 “手動特權模式”只在你明確想要修改當前 shell 環(huán)境時才用。一、為什么bash xxx.sh默認新建子進程設計初衷想象場景你下載了一個別人寫的 shell 腳本。如果腳本直接在你當前終端 shell 里跑腳本隨便執(zhí)行export直接篡改你當前終端的環(huán)境變量、PATH腳本執(zhí)行cd /你終端的當前目錄直接被改到根目錄腳本甚至可以exit直接把你的終端窗口關掉腳本出錯、環(huán)境亂掉你的終端環(huán)境直接被污染。操作系統(tǒng)和 bash 設計者的思路默認隔離保護你當前交互式 shell 環(huán)境。子進程方案腳本在獨立子 shell 里面隨便折騰。腳本里改變量、cd、export全部只在子進程副本腳本跑完子進程銷毀所有改動全部丟棄你的終端原樣不受影響副作用腳本內部設置的環(huán)境變量無法自動帶回父 shell。 這是安全優(yōu)先的設計不信任腳本默認隔離不讓它隨便污染你的交互式會話。舉個直觀例子# test.sh export CFLAGS-O3 cd /tmp echo 腳本里面$CFLAGSbash test.sh新建子 shell 運行。腳本結束回到你的終端echo $CFLAGS # 空當前目錄也沒變腳本的改動全部消失你的終端安然無恙。二、那為什么要有source.命令source 是一個顯式開關代表你信任這個腳本主動同意讓腳本修改你當前 shell 環(huán)境。典型使用場景就是你 buildroot 的場景source output/env.sh這個腳本的目的就是專門用來修改你當前終端的環(huán)境變量設置交叉編譯器 PATH、ARCH、CROSS_COMPILE 等。你希望腳本執(zhí)行完這些環(huán)境變量留在你當前終端后續(xù)敲 make/gcc 直接生效。所以source的行為不 fork 新進程直接在當前 shell 進程內逐行執(zhí)行腳本里面的代碼。腳本里的 export、cd全部作用在你正在用的終端 shell。?? 代價此時腳本擁有修改你當前環(huán)境的全部能力腳本里寫 exit 會直接關掉你的終端。所以這是你主動選擇的不是默認行為。三、對比兩種模式方式是否新建進程環(huán)境修改范圍適用場景風險bash xxx.sh? 新建子 shell只在子進程執(zhí)行完丟棄執(zhí)行自動化編譯腳本、運行第三方腳本低不會污染你的終端source xxx.sh/. xxx.sh? 不新建進程直接修改當前 shell 環(huán)境加載環(huán)境配置腳本envsetup.sh、env.sh高腳本會改動你當前終端四、補充一個容易混淆的點為什么命令行敲一行命令不會開子 shell你在終端敲export CFLAGS123 cd xxx這些是內置命令bash 直接在當前進程執(zhí)行不會 fork。外部命令ls/make才會 fork 子進程。而整個腳本文件當你用bash test.sh調用時是啟動一個全新 bash 實例子進程來解釋整個腳本。五、和你之前的知識串起來fork 會復制一份環(huán)境變量副本子進程修改副本無法傳回父進程。所以普通腳本哪怕腳本里面 export只能改子進程那份副本腳本結束就銷毀。source 不走 fork直接在當前進程執(zhí)行代碼修改當前 shell 的環(huán)境變量所以變量保留。六、一句話記憶默認子進程隔離保護防止腳本搞壞你的終端環(huán)境source手動關閉隔離專門用來加載環(huán)境變量。小思考題buildroot 的env.sh如果不用 source而是用bash env.sh執(zhí)行會發(fā)生什么答案腳本里面設置的交叉編譯環(huán)境變量全部在子進程里腳本結束就消失你當前終端完全沒有變化后面 make 找不到交叉編譯器什么是內部命令什么是外部命令都有哪些為啥會有這種區(qū)分內部命令builtinbash 程序自己自帶的代碼不需要單獨的可執(zhí)行文件外部命令獨立的二進制程序文件存在磁盤上需要 forkexec 加載運行。區(qū)分的根源性能 必要性。一、內部命令Shell 內置命令代碼直接寫在 bash 這個程序里面不需要去磁盤找單獨程序。執(zhí)行時不 fork 新進程就在當前 shell 進程直接跑。常見內部命令cd、export、set、unset、source(.)、exit、read、echo、pwd、type、break、continue if/for/while 這些語法關鍵字也屬于shell內置邏輯驗證一個命令是不是內置type 命令名type cd # cd is a shell builtin type export # export is a shell builtin關鍵特點執(zhí)行快不用 fork、不用讀磁盤加載程序直接修改當前 shell 進程狀態(tài)最重要cd修改當前 shell 的工作目錄export修改當前 shell 的環(huán)境變量exit直接退出當前 shell 進程 這類操作不能放到獨立子進程里跑如果 cd 是外部命令fork 子進程去執(zhí)行 cd只會改變子進程的目錄執(zhí)行完子進程退出你當前終端目錄完全不變cd 就毫無意義。這就是為什么 cd、export 必須做成內置命令。二、外部命令是獨立的二進制可執(zhí)行文件放在磁盤一般/bin/usr/bin。執(zhí)行流程shell 調用fork()創(chuàng)建子進程 → 在子進程exec()加載這個磁盤上的程序運行。常見外部命令ls、pwd、cat、ps、grep、make、gcc、rm、cp、mv驗證type ls # ls is /usr/bin/ls注意少數(shù)命令既有內置版本又有外部獨立程序比如pwd、echo。默認優(yōu)先用內置。你可以用/usr/bin/pwd強制調用外部版本。三、為什么要分成內部、外部命令設計原因1. 一部分操作必須操作 shell 自身狀態(tài)不能放在子進程最核心像cd、export、source它們修改的是當前 shell 進程內部的數(shù)據(jù)當前工作目錄、環(huán)境變量。如果 fork 子進程執(zhí)行子進程修改副本執(zhí)行完就銷毀父 shell 完全不受影響命令就失效。 所以這類必須做成內置命令在當前進程運行。2. 簡單小命令做成內置減少 fork 開銷提升速度echo、pwd這類簡單操作如果每次都 forkexec 去磁盤加載程序頻繁調用會很耗資源。內置版本直接在 shell 內部完成更快。3. 功能解耦復雜工具做成獨立外部程序ls、gcc、make、grep邏輯龐大不適合全部塞進 bash 里。bash 只負責命令解析、進程管理復雜功能交給獨立二進制。好處可以單獨升級 ls/gcc不用替換整個 bash其他程序python、go也可以直接調用 ls不依賴 shell四、核心對比表項目內部命令 builtin外部命令代碼位置嵌入 bash 程序內部磁盤上獨立文件/usr/bin/xxx是否 fork 新進程? 不 fork當前進程直接執(zhí)行? forkexec新建子進程運行能否修改當前 shell 環(huán)境? 可以cd、export、set? 只能修改子進程副本不影響父 shell查看方式type cmd→shell builtintype cmd→ 顯示文件路徑執(zhí)行速度快慢需要創(chuàng)建進程、讀磁盤五、容易踩坑的例子pwd既有內置也有外部程序/usr/bin/pwdtype pwd # pwd is a shell builtin /usr/bin/pwd # 強制調用外部pwd會fork子進程區(qū)分cd永遠是內置沒有/bin/cd這個文件which cd # 不會輸出任何東西因為cd沒有獨立可執(zhí)行文件六、結合你前面環(huán)境變量知識串起來export是內置命令在當前 shell 進程修改環(huán)境變量make是外部命令敲 makeshell fork 子進程復制一份當前環(huán)境變量給 makemake 內部修改環(huán)境只影響 make 子進程source是內置命令在當前 shell 逐行執(zhí)行腳本不創(chuàng)建子進程所以腳本里 export 的變量留在當前終端。補充哪怕是內置命令如果你放在()子 shell 里執(zhí)行依然會新建進程修改只在子 shell 內。(export TEST123) echo $TEST # 空括號開了子shell小練習你可以在終端執(zhí)行這幾條自己驗證type cd type export type ls type make type pwd which ls which cd管道|帶來的子 shell 陷阱一句話重點管道|默認會把管道每一段命令都放到獨立子 shell 里面執(zhí)行。哪怕里面是內置命令cd、export也會被放到子進程修改不會影響外面的 shell1. 先回憶基礎內置命令本來是在當前進程執(zhí)行不 fork。但是只要放在管道|的任意一段bash 就會創(chuàng)建子 shell 去跑這一段代碼。子 shell 一個 bash 子進程復制一份環(huán)境變量。在子 shell 里面改環(huán)境變量、cd只會修改副本退出之后全部消失父 shell 完全不受影響。2. 經(jīng)典坑示例export 管道# 管道左邊執(zhí)行export內置命令 export TESTold echo new123 | read key val echo $TEST echo $key $val你會發(fā)現(xiàn)$key和$val是空的原因拆解echo new123是外部命令開子進程輸出字符串read是內置命令但是因為在管道|的右側bash 依然新開一個子 shell 執(zhí)行read在子 shell 里面read 拿到值賦值給key val子 shell 執(zhí)行完畢直接銷毀子 shell 里的變量消失回到父 shellkey變量不存在。很多人以為 read 是內置就可以直接改父 shell 變量但是管道讓它進了子 shell賦值帶不出來。3. 再舉 cd 的例子pwd echo /tmp | cd pwd執(zhí)行完當前目錄不變cd是內置命令但是在管道的右邊運行在子 shell 里面。子 shell 里面 cd 到 /tmp子進程結束銷毀父 shell 目錄完全沒變。4. 不止管道還有哪些語法會產(chǎn)生子 shell除了|下面這些寫法都會創(chuàng)建子 shell內置命令也會隔離( command )圓括號(export ABC123) echo $ABC # 空括號里面是子shell管道|部分 bash 版本的后臺執(zhí)行cmd 也會新建子 shell對比{ command; }大括號不會創(chuàng)建子 shell注意大括號前后要有空格末尾分號不能漏{ export ABC123; } echo $ABC # 能打印出123在當前shell執(zhí)行5. 為什么 bash 管道要設計成子 shell管道本質左邊程序的標準輸出作為右邊程序的標準輸入。兩邊是兩個獨立的程序流內核管道需要兩個獨立進程來讀寫。所以 bash 最簡單的實現(xiàn)方案管道每一段都生成獨立子進程。有例外bash 有個選項lastpipe可以讓管道最后一條命令跑在當前 shell不是子 shell。但是這個選項默認不開啟而且只有非交互 shell腳本里才生效終端交互模式無效所以不要依賴它。Shell 變量 / 環(huán)境變量創(chuàng)建、導出、刪除核心區(qū)分shell 局部變量僅當前 bash 進程可見子進程看不到env命令看不到環(huán)境變量當前 shell 后續(xù) fork 出來的子進程都能繼承env、printenv可以查到一、設置【Shell 局部變量】語法變量名值等號兩邊不能有空格# 示例 MY_VARhello NUM123 # 帶空格的值必須加引號 MSGhello world? 查看局部變量echo $MY_VAR # 或者一次性列出所有shell變量包含局部環(huán)境 set?env看不到局部變量子進程也拿不到。錯誤寫法等號左右空格會報錯MY_VAR hello # 不行shell會把MY_VAR當成命令執(zhí)行二、設置【環(huán)境變量】子進程可以繼承兩種寫法效果一樣方式 1先定義局部變量再 export 導出推薦MY_VARtest export MY_VAR 導出之后MY_VAR就升級成環(huán)境變量env、子進程都能讀取。方式 2定義的時候直接 exportexport MY_VARtest? 查看環(huán)境變量env # 或者 printenv MY_VAR臨時一次性給單個命令設置環(huán)境變量只對這一條命令生效不改變當前 shell# 只在執(zhí)行env這個子進程時臨時帶上MY_TMP999 MY_TMP999 env這條不會修改你當前 shell 的變量僅本次子進程生效。三、刪除變量unset 內置命令unset是 shell 內置命令不管是局部變量還是環(huán)境變量都可以刪掉# 刪除變量 unset MY_VAR執(zhí)行完echo $MY_VAR→ 空env里面也消失?? 注意unset不能刪除只讀變量。四、完整演示你可以直接復制到終端測試# 1. 創(chuàng)建局部變量 MYE1 echo $MYE # 輸出1 env | grep MYE # 找不到因為只是局部變量 # 2. 導出為環(huán)境變量 export MYE env | grep MYE # MYE1 出現(xiàn)子進程可以讀取 # 3. 刪除變量 unset MYE echo $MYE # 空 env | grep MYE # 消失五、持久化可選重啟終端還保留上面的方法都是臨時的關閉當前終端變量就消失。想要永久生效寫到配置文件用戶級別只當前用戶~/.bashrc或者~/.profilevim ~/.bashrc # 在文件末尾添加 export MYE1保存后加載配置生效source ~/.bashrc全局所有用戶/etc/profile需要 root 權限注意set和unset不是一對正反操作很多人直覺上以為set 設置變量unset 刪除變量這是望文生義的誤解。bash 里命名不是這么配對的兩個命令的本源完全不一樣。1. unset名字本身就是「取消設置」unset是 POSIX 標準內置命令單詞含義un-set 撤銷已經(jīng) set 好的東西。它的職責刪除變量 / 函數(shù)。變量一旦被創(chuàng)建就在 shell 內存里unset xxx把這個變量從 shell 內存里拿掉。但是unset 對應的 “set”并不是創(chuàng)建普通變量。2. set 到底是干嘛的遠古歷史來源回到最早的Bourne Shellsh1979。在最原始 Unix shell 里set的原始含義設置 shell 的內部狀態(tài)、選項、位置參數(shù) ($1,$2,$3...)不是用來創(chuàng)建普通自定義變量。set 的 3 個完全獨立功能同一個命令多重用途不帶參數(shù)set打印當前 shell 所有變量局部 環(huán)境變量set -e / set -x / set -o設置 shell 的運行選項開啟 / 關閉 shell 行為set arg1 arg2設置位置參數(shù) $1、$2、$3set apple banana echo $1 # apple echo $2 # banana 你剛才踩坑的set MYE1就是這個功能把$1賦值為字符串MYE1根本不會新建 MYE 變量。? 在 sh/bash 的設計里自定義變量根本不需要一個叫 set 的命令來創(chuàng)建直接VARvalue就可以賦值這是 shell 的語法本身不是調用內置命令。重點區(qū)分VARxxxshell 語法解析一行命令的時候直接在內存創(chuàng)建 / 更新變量不調用 set 命令set單獨內置命令用來修改 shell 狀態(tài)、位置參數(shù)3. 為什么會產(chǎn)生這種違和感誤區(qū)來源英文單詞set 設置unset 取消設置你看到名字自然腦補set 變量新建變量unset 變量刪除變量。但 shell 的設計者的語境里set操作的對象是shell 選項、位置參數(shù)unset操作的對象是變量、函數(shù)set 第二種用法set -e / set -x / set -o xxx一句話概括set 用來修改 bash 自身的全局行為開關shell 選項控制腳本怎么跑、報錯怎么處理只對當前 shell 生效子 shell 不受影響。這是寫 shell 腳本最常用的 set 用法buildroot 里面大量腳本都會寫set -e、set -x。兩個寫法等價# 短選項最常用 set -e set -x # 長選項寫法用 -o set -o errexit set -o xtrace-o就是 option 的縮寫set -o 名字短選項是簡寫。 4 個最核心、最常用選項1.set -e等價set -o errexiterrexiterror exit含義如果一條命令返回非 0命令執(zhí)行失敗shell 直接退出腳本。默認行為不加 set -e# 默認就算cat找不到文件報錯腳本繼續(xù)往下跑 cat nofile.txt echo 繼續(xù)執(zhí)行執(zhí)行cat 報錯但是 echo 依然打印。加上set -e之后set -e cat nofile.txt echo 繼續(xù)執(zhí)行cat失敗腳本直接終止后面 echo 不會執(zhí)行。?? 坑管道、if 判斷里面的命令失敗set -e有時候不會觸發(fā)這個是經(jīng)典坑。2.set -x等價set -o xtracextrace追蹤打印含義執(zhí)行每一行命令前把解析后的命令打印出來調試神器。打印的行前面會帶。示例腳本set -x A100 echo $A輸出 A100 echo 100 100buildroot 編譯腳本經(jīng)常用set -x方便看腳本到底執(zhí)行了什么命令。關閉set x注意是加號關閉用開啟用-3.set -u等價set -o nounsetnounset未定義變量報錯含義使用一個沒有定義的變量直接報錯退出。默認情況引用不存在變量當成空字符串不報錯echo $NOT_EXIST輸出空腳本繼續(xù)跑。開啟set -uset -u echo $NOT_EXIST直接報錯bash: NOT_EXIST: unbound variable腳本退出。寫嚴謹腳本必開防止手敲變量名寫錯。4.set -o pipefail非常重要管道專用默認 bash 管道只看管道最后一條命令的返回碼# 管道cat不存在的文件 | grep xxx cat nofile.txt | grep abc echo $?默認cat 失敗但是 grep 成功$?返回 0你看不到前面 cat 出錯。set -o pipefail開啟之后管道里任意一個命令失敗整個管道返回失敗碼。buildroot、CI 腳本幾乎都會帶上這個。組合寫法工程最經(jīng)典#!/bin/bash set -euo pipefail這一行是 shell 腳本的 “安全三板斧”很多開源腳本開頭第一句就寫這個。查看所有可選選項set -o會列出所有 shell 選項當前是 on 還是 off。開啟 / 關閉規(guī)則set -xxx開啟該選項set xxx關閉該選項這里不是加是關閉這個地方新手超級容易搞混作用范圍只對當前 shell 進程生效。寫在腳本里腳本內部生效腳本執(zhí)行完退出終端恢復原樣。在交互式終端敲set -e當前終端生效新開終端不受影響。子 shell括號()里面不會繼承父 shell 已經(jīng)開啟的 set 選項。小實驗你直接在終端試set -x echo hello set x你會看到執(zhí)行 echo 那行會打印帶的追蹤日志set x 關閉追蹤。