最近項目組要在一個受限環(huán)境里搭一個輕量交互進程原本想直接調(diào)系統(tǒng)命令結(jié)果業(yè)務(wù)場景對命令解析、退出碼、環(huán)境變量切換的要求特別細最后干脆自己動手寫了一個簡易Shell。這篇復(fù)盤把整個過程中最核心的兩塊——內(nèi)建命令和exec程序替換——拆開講清楚也是給自己留一份可回看的筆記。說句實話寫Shell這件事很多同學(xué)覺得是操作系統(tǒng)課程的作業(yè)題其實它是一面很有價值的鏡子你會在里面看到進程、文件描述符、環(huán)境變量、信號處理這些概念在真實代碼里是怎么協(xié)作的。如果你正在學(xué)C語言、準備系統(tǒng)編程面試或者工作中要跟subprocess、進程管理打交道這篇內(nèi)容可以直接拿來對照參考。全文不涉及太花哨的框架就是純C實現(xiàn)把主干邏輯走通。2. fork與exec這對組合程序替換的底層邏輯2.1 進程不是憑空出現(xiàn)的要理解Shell先要理解一個事實在Unix世界里創(chuàng)建一個新進程從來不是直接啟動某個程序而是分兩步走。第一步是fork()它把當(dāng)前進程復(fù)制一份復(fù)制出來的子進程擁有和父進程幾乎一樣的地址空間、文件描述符、環(huán)境變量。第二步是exec系列函數(shù)它在當(dāng)前進程里加載一個新的可執(zhí)行文件把原來的代碼段、數(shù)據(jù)段、堆棧全部替換掉然后從新程序的main()開始執(zhí)行。這兩個步驟合在一起才是我們平時說的運行一個程序。打個比方fork()就像你用復(fù)印機復(fù)印了一份文件復(fù)印紙上原本寫的是舊內(nèi)容exec則是把復(fù)印紙上的內(nèi)容全部擦掉重新寫上你要的新內(nèi)容。不先復(fù)印就直接擦寫那會把你自己手里唯一的一份文件也毀掉。所以Shell必須先fork()一個子進程再由子進程去exec這樣即使新程序崩潰也不會影響Shell本身。這也是為什么主流的Shell都是這樣實現(xiàn)外部命令的父進程負責(zé)等待和回收子進程負責(zé)干活。2.2 exec族函數(shù)怎么選exec不是只有一個函數(shù)而是一族函數(shù)C標(biāo)準庫提供了六個函數(shù)名路徑來源參數(shù)傳遞方式環(huán)境變量來源execl顯式路徑變長參數(shù)列表繼承當(dāng)前環(huán)境execv顯式路徑argv數(shù)組繼承當(dāng)前環(huán)境execle顯式路徑變長參數(shù)列表顯式envpexecve顯式路徑argv數(shù)組顯式envpexeclp自動搜索PATH變長參數(shù)列表繼承當(dāng)前環(huán)境execvp自動搜索PATHargv數(shù)組繼承當(dāng)前環(huán)境很多初學(xué)者看到這一堆函數(shù)就頭大其實記憶方法很簡單。后綴里帶llist表示參數(shù)一個一個列出來帶vvector表示參數(shù)放在一個字符串?dāng)?shù)組里帶ppath表示函數(shù)會自己搜索PATH環(huán)境變量找到可執(zhí)行文件不帶p的就要你給出文件路徑帶eenvironment表示你可以自己指定環(huán)境變量。我實現(xiàn)簡易Shell時首選的是execvp()原因有二。第一它自動搜索PATH這恰好符合我們平時在Shell里直接敲ls、grep就能運行的習(xí)慣。第二參數(shù)用數(shù)組傳遞結(jié)構(gòu)上和后面要做的命令解析天然契合——我解析完命令行已經(jīng)得到了一個char *argv[]數(shù)組直接傳給execvp就行。注意execl這類變長參數(shù)形式看著方便但參數(shù)個數(shù)固定寫死的話后面想擴展命令參數(shù)就痛苦了。實際項目中能用execv系的就別用exec系。2.3 一個最小可運行的exec演示先看一段最簡代碼確認這個機制跑得通#include stdio.h #include unistd.h #include sys/wait.h int main(void) { pid_t pid fork(); if (pid 0) { // 子進程 // 用 execvp 去執(zhí)行 ls參數(shù)數(shù)組以 NULL 結(jié)尾 char *argv[] {ls, -l, NULL}; execvp(ls, argv); // 如果 execvp 失敗了下面這行才會執(zhí)行 perror(execvp failed); _exit(127); // 127 是“找不到命令”的慣例退出碼 } else if (pid 0) { // 父進程等待子進程結(jié)束 int status; waitpid(pid, status, 0); printf(子進程退出碼: %d\n, WEXITSTATUS(status)); } else { perror(fork failed); } return 0; }這段代碼的邏輯很清晰子進程里調(diào)用execvp成功的話ls的輸出會直接打到終端上失敗的話才走到perror和_exit(127)。這里有一個細節(jié)很多人會忽略——為什么失敗后要用_exit而不是return或exit因為子進程是從父進程的fork復(fù)制出來的如果exec失敗后你使用exit()退出它會刷新stdio緩沖區(qū)把父進程緩沖尚未輸出的數(shù)據(jù)也一并沖出去可能導(dǎo)致輸出重復(fù)更危險的是它還會執(zhí)行父進程注冊的atexit鉤子。正確的做法是使用_exit()它直接進入內(nèi)核退出路徑不做任何用戶態(tài)清理這才是子進程exec失敗的規(guī)范姿勢。2.4 為什么要先fork再exec這個問題我在帶新人時被問過很多次。有人覺得直接在當(dāng)前Shell進程里exec不就行了反正Shell已經(jīng)完成了對命令的解析執(zhí)行完替換掉自己也沒啥問題。問題在于如果Shell在exec時被替換了它就沒法回到原來的命令行循環(huán)了。你敲一條命令Shell進程就變成那條命令的進程命令執(zhí)行完整個終端也死了不可能再給你第二次輸入提示符。所以必須有fork這層復(fù)制把執(zhí)行命令這件事隔離到子進程里父進程穩(wěn)定地留在外面等待。這句話是理解進程模型的關(guān)鍵也直接引出后面的wait機制。3. 內(nèi)建命令為什么Shell必須“親自下場”3.1 cd暴露出的父子進程問題你寫一個最簡單的Shell解析用戶輸入forkexec執(zhí)行。跑起來后發(fā)現(xiàn)一個尷尬的問題——cd命令失效了。你的Shell執(zhí)行cd /tmp調(diào)用execvp(cd, ...)系統(tǒng)提示找不到cd這個程序或者在某些系統(tǒng)上能運行但你的Shell當(dāng)前目錄根本沒變。原因是cd并不是一個外部程序它其實是改變了Shell進程自身的當(dāng)前工作目錄。chdir()這個系統(tǒng)調(diào)用只能影響調(diào)用它的進程。如果你fork一個子進程去chdir子進程的工作目錄確實變了可子進程干完活就退出了父進程的Shell還是留在原來的目錄。這就像你想搬辦公室卻讓快遞員幫你搬——快遞員到了新辦公室你自己還在原地。所以cd必須由Shell進程自己執(zhí)行不能派發(fā)給子進程。這類由Shell自己實現(xiàn)、不依賴外部可執(zhí)行文件的命令就叫內(nèi)建命令builtin command。3.2 內(nèi)建命令和外部命令的本質(zhì)區(qū)別這個問題是面試高頻題。區(qū)別可以概括為外部命令通過fork()exec()在子進程中運行命令結(jié)束后Shell不受任何影響比如ls、grep、cat。內(nèi)建命令Shell進程自己調(diào)用對應(yīng)函數(shù)處理不創(chuàng)建子進程因此可以直接修改Shell的狀態(tài)比如cd、exit、export。為什么要區(qū)分因為有些操作只能在當(dāng)前進程內(nèi)完成任何子進程都不行。影響當(dāng)前Shell的狀態(tài)的東西必然是內(nèi)建命令。順帶說一句很多人以為echo一定是內(nèi)建命令其實不然。Bash里echo既有內(nèi)建版本也有一個位于/bin/echo的外部版本具體用哪個要看調(diào)用方式。在bash里直接敲echo用的是內(nèi)建版本但如果你寫/bin/echo hello那就是外部程序。這一類“二合一”命令挺容易踩坑的后面我會單獨說。3.3 一個最小內(nèi)建命令集我把實現(xiàn)一個可用Shell需要的最少內(nèi)建命令列了出來并標(biāo)注了每個命令的核心職責(zé)命令為什么必須內(nèi)建核心動作cd改變當(dāng)前目錄只能影響當(dāng)前進程chdir()exit終止Shell進程本身設(shè)置退出碼后exit()export設(shè)置環(huán)境變量必須影響當(dāng)前Shell及其后代setenv()unset刪除環(huán)境變量unsetenv()set查看/設(shè)置Shell變量變量表操作echo雖可不內(nèi)建但內(nèi)建避免依賴外部程序printf輸出實際寫一個入門級Shell至少把cd、exit、export做掉否則這個Shell用戶連切換目錄和退出都做不到。3.4 內(nèi)建命令的一種優(yōu)雅實現(xiàn)內(nèi)建命令的實現(xiàn)思路很簡單在執(zhí)行派發(fā)之前先用strcmp()比對命令名命中內(nèi)建列表就直接在當(dāng)前進程調(diào)用對應(yīng)函數(shù)。int builtin_cmd(char **args) { if (args[0] NULL) return 0; if (strcmp(args[0], cd) 0) { const char *path args[1] ? args[1] : /root; if (chdir(path) ! 0) { perror(cd failed); return 1; } return 1; } if (strcmp(args[0], exit) 0) { int code args[1] ? atoi(args[1]) : 0; exit(code); } if (strcmp(args[0], export) 0) { if (args[1]) { char *eq strchr(args[1], ); if (eq) { *eq \0; setenv(args[1], eq 1, 1); } } return 1; } return 0; }這里我特別強調(diào)返回值的設(shè)計builtin_cmd返回1表示“這個命令已經(jīng)被我處理了”返回0表示“這不是內(nèi)建命令你再去走forkexec流程”。這個約定的好處是主循環(huán)代碼很干凈不用每加一個內(nèi)建命令就改一次主循環(huán)結(jié)構(gòu)。3.5 誤把內(nèi)建當(dāng)外置的經(jīng)典翻車現(xiàn)場我在給別人做代碼評審時見過一個很典型的錯誤有人用system(cd /tmp)來實現(xiàn)自己的Shell的cd命令。system()內(nèi)部其實也是forkexec它啟動了一個新的Shell去執(zhí)行cd /tmp當(dāng)你回到你自己的Shell進程時目錄還是原來的。這個坑和fork子進程去chdir完全一樣只是多了一層system的封裝更容易迷惑新手。還有一個不太容易發(fā)現(xiàn)的坑如果你的Shell接管了用戶的PATH那當(dāng)你執(zhí)行export PATH/custom/path之后再去外部命令ls會發(fā)現(xiàn)找不到命令了。所以寫export內(nèi)建命令時一定要考慮它對外部命令搜索的影響。成熟的Shell會用安全路徑兜底不會讓你把自己鎖死。4. 手寫Shell的主循環(huán)實現(xiàn)從字符流到命令執(zhí)行4.1 整體架構(gòu)讀入-解析-執(zhí)行一個Shell的運行骨架本質(zhì)上是一個不斷循環(huán)的“讀取-解析-執(zhí)行”過程。我用一張流程拆解圖來描述邏輯順序Shell啟動后打印提示符然后用getline()讀入一行字符串接著把這行字符串拆分成一個個單詞構(gòu)成argv數(shù)組最后根據(jù)argv[0]判斷走內(nèi)建命令還是外部命令。這個設(shè)計不是我想出來的它源自Unix經(jīng)典工具哲學(xué)一個程序只做一件事。所以我把它拆成了三個獨立函數(shù)shell_readline()、shell_parse()、shell_execute()每個函數(shù)職責(zé)單一調(diào)試時也方便定位問題。4.2 命令解析的細節(jié)解析階段看起來簡單就是把一行字符串按空白字符拆開但細節(jié)處有講究。我用strtok()是因為它把連續(xù)的分隔符自動折疊輸入里多幾個空格也不會產(chǎn)生空參數(shù)但它會修改原字符串所以我會先復(fù)制一份再拆。char **shell_parse(char *line) { int bufsize 64, position 0; char **tokens malloc(bufsize * sizeof(char *)); char *token strtok(line, \t\r\n); while (token ! NULL) { tokens[position] strdup(token); if (position bufsize) { bufsize 64; tokens realloc(tokens, bufsize * sizeof(char *)); } token strtok(NULL, \t\r\n); } tokens[position] NULL; return tokens; }注意兩個點第一strtok的分隔符集合要包含\t、\r、\n否則用戶敲完命令按回車\n會黏在最后一個單詞上導(dǎo)致命令名匹配失敗。第二每次拆分出來的token要用strdup()復(fù)制一份否則后面釋放line時這些指針就懸空了。4.3 執(zhí)行派發(fā)邏輯執(zhí)行函數(shù)是核心它只有兩個分支int shell_execute(char **args) { if (args[0] NULL) return 0; // 空命令直接略過 if (builtin_cmd(args)) { return 1; } pid_t pid fork(); if (pid 0) { execvp(args[0], args); perror(myshell: command not found); _exit(127); } else if (pid 0) { perror(fork error); return 1; } int status; waitpid(pid, status, 0); return 1; }派發(fā)順序很關(guān)鍵先檢查內(nèi)建命令再走外部命令。如果反過來你敲exit時會先fork一個子進程子進程里執(zhí)行exit退出了父進程還在等結(jié)果是Shell永遠退不出去。這個順序問題經(jīng)常有人搞反。4.4 主循環(huán)與退出碼回收主循環(huán)部分反而最簡單int main(void) { char *line; char **args; int status 1; while (status) { printf(myshell ); fflush(stdout); line shell_readline(); args shell_parse(line); status shell_execute(args); free(args); free(line); } return 0; }這里有個容易被忽略的細節(jié)打印提示符之后要fflush(stdout)。因為stdout在終端下通常是行緩沖但如果你重定向到文件或管道就變成全緩沖了不刷新的的話提示符可能延遲出現(xiàn)。實測很多初學(xué)者寫的Shell在管道環(huán)境下看不到提示符就是栽在這。4.5 邊緣情況的處理我在項目里還處理了幾個容易讓人懵的場景用戶直接按回車解析后args[0]是NULLshell_execute直接返回1Shell繼續(xù)循環(huán)不能報錯退出。命令行末尾帶注釋符號簡易版可以直接忽略這需要解析階段處理#。exit帶參數(shù)比如exit 3要能用atoi轉(zhuǎn)成退出碼否則用戶無法控制腳本的返回狀態(tài)。子進程被信號殺掉waitpid返回后WIFSIGNALED(status)能檢查出來進階版可以打印“被信號X終止”。這五個邊緣場景加起來不過二十行代碼但對穩(wěn)健性的提升非常明顯。很多人寫完Shell跑幾個正常命令就覺得完事了結(jié)果一遇空輸入就段錯誤一遇信號就exit不了全是在這些細節(jié)上失守。5. 實測復(fù)盤我踩過的坑與排查思路5.1 僵尸進程是怎么產(chǎn)生的寫Shell繞不開waitpid。我第一次寫完主循環(huán)后跑了幾個命令然后去開另外一個終端執(zhí)行ps aux | grep myshell發(fā)現(xiàn)一堆defunct狀態(tài)的僵尸進程。原因很直接父進程沒有及時回收子進程。我一開始為了“簡化”fork之后沒調(diào)用waitpid以為子進程執(zhí)行完就自動消失。實際上子進程退出時內(nèi)核會把它的退出狀態(tài)保留在進程表里直到父進程調(diào)用wait()或waitpid()取走狀態(tài)為止。父進程之前一直不調(diào)用wait那些子進程就會一直占著進程表項數(shù)量多了還會達到進程數(shù)上限。修復(fù)方式是每個外部命令執(zhí)行完后同步waitpid這也符合簡易Shell的語義——用戶輸了一條命令Shell等它執(zhí)行完再顯示下一條提示符。如果你只是想演示異步行為那就要用SIGCHLD信號加非阻塞wait那是后續(xù)擴展的范疇當(dāng)前階段我把同步等待作為默認行為。5.2 exec失敗后直接返回到父進程代碼是個大坑這是我調(diào)試時最兇險的一次。我起初在子進程里這樣寫pid_t pid fork(); if (pid 0) { execvp(args[0], args); // 某個錯誤情況你沒寫 _exit perror(exec failed); return -1; // 這個return是致命的 }表面看沒什么問題exec失敗打一行錯誤返回-1。但注意這里的return返回的并不是“子進程的main函數(shù)返回”而是返回到shell_execute()函數(shù)的調(diào)用棧里因為fork出來的子進程和父進程共享這份代碼子進程在execvp失敗后回到shell_execute繼續(xù)往下走就會執(zhí)行后面的waitpid邏輯而子進程此刻已經(jīng)是父進程的執(zhí)行流最終可能導(dǎo)致整個Shell邏輯錯亂甚至出現(xiàn)兩個進程同時打印提示符。修正后的黃金法則是子進程里exec如果失敗必須用_exit()結(jié)束自己永遠不允許返回到公共代碼路徑。這一點怎么強調(diào)都不為過。5.3 echo、cd、exit這三個“偽內(nèi)置”最容易讓人迷惑我在實際使用中遇到一個很有意思的case。同事說他的Shell能執(zhí)行cd但每次cd完再運行pwd目錄確實變過來了可他手賤敲了一個/bin/cd /tmp結(jié)果目錄沒變他百思不得其解。其實我猜他的Shell在實現(xiàn)時就踩了一個坑它讓cd走了外部命令路徑——系統(tǒng)里碰巧存在/bin/cd這個程序的話fork子進程去運行它子進程chdir成功了父進程目錄不變。所以他直接敲cd沒變目錄只是被程序“看似運行成功”騙了而我寫的Shell則把cd強行放到了builtin_cmd迷宮里同樣遇到這種情況時才有基準可以對比驗證。還有一個容易踩的坑是echo。如果你把echo做成外部調(diào)用在子進程里執(zhí)行/bin/echo hello輸出雖然能顯示但沒法處理echo -n不換行這類帶選項的參數(shù)而且每次都要fork性能也差。所以我的項目里把echo也做了內(nèi)建直接用printf處理。5.4 交互模式下的緩沖亂序這是終端編程里很經(jīng)典的問題Shell打印提示符“myshell ”然后執(zhí)行外部命令ls輸出的文件列表應(yīng)該顯示在提示符后面。但實測發(fā)現(xiàn)有時候文件列表跑到提示符前面去了順序完全顛倒。問題出在提示符和ls的輸出緩沖方式不一樣。我的提示符用的是printfstdout在終端下是行緩沖而ls的輸出是直接寫到stdout文件描述符的。如果我打印提示符后沒有fflush(stdout)提示符可能還躺在緩沖區(qū)里ls的輸出已經(jīng)先到了終端。修復(fù)方法很簡單就是我在主循環(huán)里寫的那個fflush(stdout)這個細節(jié)在書本上經(jīng)常被一筆帶過實際編碼時卻能把人折騰半天。5.5 子進程繼承的“隱形遺產(chǎn)”最后說一個代碼之外的問題。子進程通過fork繼承父進程的所有文件描述符等資源如果你的Shell之前打開過一個文件但沒關(guān)閉那么子進程執(zhí)行g(shù)rep時也會持有這個fd一旦外部命令和這個文件有交互可能造成文件鎖沖突或者資源泄漏。在我自己的項目里我一開始沒注意這個后來跑一個長時間日志分析腳本發(fā)現(xiàn)打開的文件數(shù)量爆炸排查到最后發(fā)現(xiàn)是Shell每個外部命令的fork都繼承了那個日志fd。解決方案是設(shè)計Shell時保持文件描述符的整潔該關(guān)閉的就關(guān)閉或者必要時在子進程里顯式關(guān)閉無關(guān)fd。這也是一個能體現(xiàn)你系統(tǒng)編程功力的小細節(jié)。6. 下一步擴展重定向、管道與真正的Shell還差什么6.1 重定向的本質(zhì)是文件描述符寫完基礎(chǔ)的forkexec之后我自然而然地想加和重定向。一直以為重定向很神奇其實它的本質(zhì)就是文件描述符的重新綁定。比如ls out.txt意思是把ls的標(biāo)準輸出從終端換成文件out.txt。實現(xiàn)時在子進程執(zhí)行exec之前先用open()打開目標(biāo)文件再用dup2(fd, STDOUT_FILENO)把文件描述符復(fù)制到1號位置然后關(guān)閉原fd最后再execvp。這樣新程序看到的stdout已經(jīng)指向文件了。if (redir_out ! NULL) { int fd open(redir_out, O_WRONLY | O_CREAT | O_TRUNC, 0644); dup2(fd, STDOUT_FILENO); close(fd); } execvp(args[0], args);這個方法同樣適用于輸入重定向只需把dup2的目標(biāo)換成STDIN_FILENO。學(xué)到了這個思路就覺得重定向一點神秘感都沒有了。6.2 管道是重定向的進階管道ls | grep xxx的實現(xiàn)比單純重定向多了一個pipe()系統(tǒng)調(diào)用。pipe()會創(chuàng)建一對文件描述符一個讀端、一個寫端。實現(xiàn)“左命令的輸出作為右命令的輸入”本質(zhì)就是讓左命令的stdout指向管道寫端讓右命令的stdin指向管道讀端。int fd[2]; pipe(fd); if (pid_left 0) { dup2(fd[1], STDOUT_FILENO); close(fd[0]); close(fd[1]); execvp(left_args[0], left_args); } if (pid_right 0) { dup2(fd[0], STDIN_FILENO); close(fd[1]); close(fd[0]); execvp(right_args[0], right_args); }這里有個必須注意的坑管道兩端必須在fork之前創(chuàng)建這樣兩個子進程都能繼承到這對fd而每個子進程里要立刻關(guān)閉自己不需要的那一端否則會因為還有進程持有寫端導(dǎo)致讀端無法讀到EOF命令會卡住。6.3 作業(yè)控制是更深的江湖再往后如果你想讓Shell支持fg、bg這樣的作業(yè)控制光靠fork和exec就不夠了還得引入進程組、會話、信號處理這些機制。作業(yè)控制的核心是把每個管道中的子進程放進一個獨立的進程組然后用tcsetpgrp()把終端前臺進程組切換過去這樣用戶按CtrlC時信號只會發(fā)給當(dāng)前前臺進程組不會殃及Shell自己。我目前的簡易Shell還沒有完整支持作業(yè)控制但每次寫完一個擴展都讓我更理解終端驅(qū)動和進程管理的關(guān)系。這個升級路徑是清晰的解析階段多識別一個執(zhí)行階段把同步wait換成waitpid加WNOHANG再加上一個作業(yè)表維護后臺進程就搭起一個可以繼續(xù)深入的框架。6.4 從迷你Shell到主流Shell還差哪些東西把基礎(chǔ)版和真正的Bash對比一下你會發(fā)現(xiàn)差距主要集中在這幾塊豐富的語法比如if、for、while需要實現(xiàn)ast級別的語法解析。命令別名和函數(shù)定義需要在Shell內(nèi)部維護一個符號表。歷史記錄、自動補全需要讀入歷史文件并做交互優(yōu)化。腳本執(zhí)行能力需要把整段腳本解析成AST后逐條執(zhí)行這已經(jīng)上升到解釋器層面了。我自己完成簡易Shell之后最大的體會是寫一個“能跑”的Shell只需要一小段代碼寫一個“像樣”的Shell則可以一直寫下去。很多人學(xué)完fork和exec覺得沒什么了不起但當(dāng)你真的親手把提示符、內(nèi)建命令、程序替換、退出碼這些串成一個閉環(huán)之后你會對“命令行是一個進程還是多個進程”“Shell為什么能改變環(huán)境”“管道為什么能讓命令協(xié)作”這些之前只停留在紙面上的問題產(chǎn)生完全不一樣的理解。最后分享一個我在實際開發(fā)中的小技巧調(diào)試Shell進程時不要只盯著printf輸出多開一個終端用ps -ef --forest觀察進程樹看看它的父子關(guān)系是不是符合預(yù)期。很多詭異的Shell行為看一眼進程樹就能當(dāng)場破案。這個習(xí)慣我用了很久每次排查進程相關(guān)問題都特別高效。