1. 為什么要在2025年親手寫一個Shell這個項目比你想的更值錢先別急著關頁面。我知道你的第一反應是Shell不是現(xiàn)成的嗎Bash、Zsh、Fish隨便挑一個都比自己寫的強我干嘛要自討苦吃這個反應沒錯但恰恰是問題所在。現(xiàn)成的Shell把你該學的東西都藏起來了。你在終端里敲ls -l | grep txt的時候Bash替你做了三件事解析字符串、創(chuàng)建管道、拉起子進程。這三件事每一個都是操作系統(tǒng)核心機制的實戰(zhàn)考點而你平時根本看不見它們。我見過太多人Linux命令敲得飛起但一問fork()和exec()的區(qū)別就卡殼能寫出幾百行的Shell腳本卻不理解為什么管道兩端的命令是“同時”運行的。倒不是說他們笨而是工具太好的時候人對底層機制會失去感知。這就跟開自動擋開久了不會開手動擋一樣不是技術問題是習慣問題。自定義Shell這個項目本質(zhì)上就是把你平時用的黑盒打開讓你看看里面是什么。你不需要做出一個能和Bash抗衡的產(chǎn)品你只需要做出一個能跑ls、cd、cat file | grep foo、./program out.txt的“玩具”——但這趟走下來你對Linux進程模型、文件描述符、字符串處理的理解會比你讀三章APUE來得扎實。而且實用性也很強。很多公司面試會問“設計一個迷你Shell”或者讓你在紙上寫fork exec wait的組合代碼。你親手寫過一遍這種題就是送分題。退一步說就算不為了面試理解Shell的工作方式對你寫配置腳本、排查啟動問題、理解Docker容器的進程行為都有直接幫助——因為你終于知道那些“神奇”的操作底下到底發(fā)生了什么。下面我直接把這套實現(xiàn)拆開講從項目結(jié)構(gòu)、核心機制到具體代碼、踩坑記錄一條線走完。2. 動手前的核心知識儲備進程模型、系統(tǒng)調(diào)用與解析器設計的底層邏輯寫Shell之前必須先建立三個底層認知。這三點如果不提前搞清楚寫出來的東西大概率是“看起來像Shell跑起來全是病”。2.1 進程模型Shell其實是個“包工頭”Linux下的進程模型一句話概括就是進程是“復制”出來的不是“創(chuàng)建”出來的。所有用戶態(tài)進程都是從一個叫init的祖先進程一路fork()復制出來的。關鍵認知是一個程序跑起來之后你通常有兩個實體——父進程和子進程。父進程負責“管理”子進程負責“干活”。Shell就是父親的典型代表它接收你輸入的命令然后fork()出一個子進程再在子進程里用exec()把命令真正換上去。打個比方。Shell是包工頭你讓他蓋一棟樓執(zhí)行命令他不會自己上腳手架而是打電話叫一隊工人fork()一個新進程然后告訴工人具體干什么活exec()把程序加載進來。包工頭自己在旁邊蹲著等工人干完wait()好匯報給你。這跟我們平時跑程序的感覺完全不一樣。我們直覺上覺得“程序是被操作系統(tǒng)創(chuàng)建出來的”但Linux底下的語言是先復制一份當前狀態(tài)再替換成新程序。這兩個步驟必須拆開理解否則你會對整個Shell的實現(xiàn)邏輯產(chǎn)生疑惑。2.2 三大系統(tǒng)調(diào)用fork、exec、wait這是Shell的基石必須吃透。fork()調(diào)用一次返回兩次。一次在父進程里返回子進程的PID一次在子進程里返回0。返回值是負則說明創(chuàng)建失敗。這段代碼pid_t pid fork(); if (pid 0) { // 子進程這里繼續(xù)跑的是從父進程復制過來的代碼副本 } else if (pid 0) { // 父進程pid 就是子進程的進程ID } else { perror(fork); }很多人不理解“返回兩次”是怎么回事。換個說法fork()完成那一刻系統(tǒng)里憑空多了一個進程這個進程和父進程幾乎一模一樣連程序計數(shù)器PC的位置都一樣。也就是說子進程從fork()返回的那一行開始繼續(xù)執(zhí)行同一份代碼。唯一能區(qū)分兩人的就是返回值——父進程拿到的是子進程的PID子進程拿到的是0。exec()注意它不是函數(shù)而是一族函數(shù)——execl、execv、execvp等等。它們的作用是一個進程把自己“換掉”把當前進程的代碼段、數(shù)據(jù)段、棧全部替換成新程序的然后從頭開始跑新程序。成功的話不會返回失敗才返回 -1。我們后面統(tǒng)一用execvp()因為它的第二個參數(shù)直接接受一個字符串數(shù)組argv形式對解析命令行特別方便。wait()/waitpid()父進程調(diào)用這個就會阻塞直到某個子進程結(jié)束。這個“阻塞”很重要——Shell必須等命令執(zhí)行完才能顯示下一行提示符這跟你在終端里的直覺體驗一致。三者合起來的完整流程父進程讀入一行命令fork()出子進程子進程調(diào)用execvp()變成那條命令本身父進程調(diào)用waitpid()等子進程退出子進程退出后父進程打印提示符繼續(xù)讀下一條命令。這個循環(huán)永遠不會變Shell的一切都是圍繞它展開的。2.3 解析器設計把“字符串”變成“參數(shù)數(shù)組”Shell讀到的是一行字符串比如ls -l /home/user。但execvp()需要的是char *argv[] {ls, -l, /home/user, NULL};所以你要做的是把char *line變成char **args。這個過程叫命令行解析是整個項目里最考驗“耐煩心”的部分——它不涉及什么高深算法但全是邊界條件。一個常見的誤區(qū)是別只用空格拆分。因為Shell命令里可以有引號echo hello world和轉(zhuǎn)義echo hello\ world粗暴按空格拆會把hello world拆成兩個參數(shù)。我們第一版可以不管引號但你要知道這個邊界存在否則后續(xù)擴展時容易翻車。我會用strsep()這個不太常見的函數(shù)來做拆分原因后面正文里說。它比strtok()安全——strtok()內(nèi)部有靜態(tài)變量線程不友好而且會把連續(xù)分隔符跳過有時候這不是你想要的。解析器可以分兩步走先用一個函數(shù)把整行命令按空白拆成獨立單詞再把結(jié)果整理成NULL結(jié)尾的指針數(shù)組。任何哈希、樹結(jié)構(gòu)、復雜狀態(tài)機在這個項目里都是過度設計——你需要的只是循環(huán)、指針、和一點點耐心。3. 第一個能跑的Shell骨架從main函數(shù)到循環(huán)框架好基礎打完了開始寫代碼。我不會一次性給你一個900行的完整項目而是從最小的骨架開始一步步長出一個能用的Shell。3.1 用getline()讀入命令比你想的要注意更多細節(jié)讀取命令行的標準做法是getline()它自動管理緩沖區(qū)比你用fgets()滿省心得多。核心代碼#define _GNU_SOURCE #include stdio.h #include stdlib.h #include string.h char *line NULL; size_t bufsize 0; ssize_t nread getline(line, bufsize, stdin); if (nread -1) { // EOF 或出錯 free(line); exit(0); } // 去掉末尾換行符 line[strcspn(line, \n)] \0;三個易踩的坑坑1getline()返回的是ssize_t不是int。無符號類型和有符號類型比較時會有隱式轉(zhuǎn)換問題編譯器會報警告。養(yǎng)成用ssize_t的習慣?？?去掉換行符千萬別用strlen(line) - 1。如果文件最后一行沒有換行符strlen減一就把合法字符刪掉了。用strcspn(line, \n)找到換行符的位置安全得多?？?命令行過長時getline()會自動擴容緩沖區(qū)不用你操心。但這也意味著你必須free()否則每次循環(huán)都泄漏一段內(nèi)存。別偷懶。3.2 主循環(huán)框架“讀命令 - 解析 - 執(zhí)行 - 等待”的無限循環(huán)Shell的本質(zhì)就是一個死循環(huán)退出條件只有兩個用戶敲exit或者輸入流遇到EOF比如按CtrlD。int main(void) { char *line NULL; size_t bufsize 0; ssize_t nread; while (1) { printf(mysh ); fflush(stdout); // 一定要有 nread getline(line, bufsize, stdin); if (nread -1) { printf(\n); break; // EOF 退出 } line[strcspn(line, \n)] \0; // 空命令直接跳過 if (strlen(line) 0) continue; char **args parse_command(line); if (args[0] NULL) { free(args); continue; } // 檢查是不是內(nèi)建命令是的話直接執(zhí)行不是再fork if (is_builtin(args[0])) { run_builtin(args); } else { run_external(args); } free(args); } free(line); return 0; }這段代碼展示了整體骨架。注意fflush(stdout)這一行——沒有它提示符可能不會立即顯示尤其在管道或腳本環(huán)境下。這是初學者最容易忽略的細節(jié)之一后面會說更多。3.3parse_command()我為什么推薦strsep()而不是strtok()解析函數(shù)要把ls -l /home變成{ls, -l, /home, NULL}。我推薦用strsep()char **parse_command(char *line) { int bufsize 64; int index 0; char **args malloc(bufsize * sizeof(char *)); char *token; if (!args) { perror(malloc); exit(EXIT_FAILURE); } char *rest line; while ((token strsep(rest, \t\r\n)) ! NULL) { if (*token \0) continue; // 跳過連續(xù)空白 args[index] token; index; if (index bufsize) { bufsize 64; args realloc(args, bufsize * sizeof(char *)); if (!args) { perror(realloc); exit(EXIT_FAILURE); } } } args[index] NULL; return args; }為什么不用strtok()三個理由每一個都夠你在生產(chǎn)環(huán)境里吃一次虧1. 線程安全。strtok()內(nèi)部維護了一個靜態(tài)變量來保存剩余字符串位置多個線程同時調(diào)用會串數(shù)據(jù)。Shell雖然是單線程的但這個壞習慣不值得養(yǎng)成。strsep()用局部變量rest手動控制。2. 連續(xù)空白符的處理粒度不一樣。strtok()默認把連續(xù)分隔符當成一個strsep()會返回空字符串需要你手動跳過。看起來是多寫了一行但給了你更多控制權(quán)。3. 解析失敗時便于排查。因為你每一步都在自己的局部變量上進行斷點調(diào)試時可以看到全部中間狀態(tài)。這里有個關鍵細節(jié)args數(shù)組里的指針直接指向原line字符串里的位置。也就是說解析沒有strdup沒有新分配內(nèi)存只是把原來的空格替換成\0然后記錄每個單詞的起點。這樣解析速度極快但代價是——你必須保證line在args使用期間不被釋放或修改。在我們的主循環(huán)里args在run_external()返回后才被釋放而execvp()在子進程里已經(jīng)完成加載所以沒問題。3.4 執(zhí)行外部命令fork execvp waitpid 的標準模板run_external()是核心中的核心void run_external(char **args) { pid_t pid fork(); if (pid -1) { perror(fork); return; } if (pid 0) { // 子進程直接替換成目標程序 if (execvp(args[0], args) -1) { perror(execvp); exit(EXIT_FAILURE); // 必須exit否則會繼續(xù)跑父進程的循環(huán) } } else { // 父進程等待子進程完成 int status; if (waitpid(pid, status, 0) -1) { perror(waitpid); return; } // 可以在這里檢查 status判斷命令是否正常退出 } }這段代碼你倒背如流也不過分。但我必須強調(diào)一個致命細節(jié)子進程里調(diào)用execvp()失敗后必須立即exit(EXIT_FAILURE)。如果漏掉這行子進程就會繼續(xù)往下執(zhí)行進入父進程的循環(huán)邏輯然后子進程也跑去讀命令、fork進程——你就獲得了一群裂變出來的Shell。這是新手最容易犯、后果最嚴重的錯誤。在子進程分支里永遠記住exec一族函數(shù)成功就不返回失敗也必須立即退出。還有一點execvp()找可執(zhí)行文件依賴環(huán)境變量PATH。它內(nèi)部會自動搜索PATH目錄下的可執(zhí)行文件。你傳入的args[0]如果是簡單的ls它就會去/usr/bin等目錄找。如果想執(zhí)行當前目錄下的程序用戶必須輸入./a.out像真正的Shell一樣。4. 內(nèi)建命令的處理為什么必須自己實現(xiàn)cd、exit、echo你可能想問cd不也是一個可執(zhí)行文件嗎我直接execvp(cd, args)不就行了不行。原因得從進程模型里找——你還記得吧子進程是父進程的“復制品”子進程里改了什么都不會影響父進程。cd的本質(zhì)是改變進程的當前工作目錄這屬于進程自身狀態(tài)。如果你fork()一個子進程去執(zhí)行cd子進程的工作目錄變了但父進程Shell本體的工作目錄紋絲不動。等你回到主循環(huán)打出下一個提示符目錄還是原來那個。這就是“內(nèi)建命令必須由Shell進程自己執(zhí)行”的根本原因。內(nèi)核態(tài)的表現(xiàn)也是如此改變工作目錄的是chdir()系統(tǒng)調(diào)用它只對發(fā)起調(diào)用的進程起作用。沒有一條路能讓子進程去改父進程的工作目錄某些調(diào)試器玩法另說但那不是普通命令的路徑。4.1cd的實現(xiàn)比你想的復雜一點點int mysh_cd(char **args) { if (args[1] NULL) { // 沒有參數(shù)回到主目錄 const char *home getenv(HOME); if (home NULL) { fprintf(stderr, mysh: cd: HOME not set\n); return 1; } if (chdir(home) ! 0) { perror(mysh: cd); return 1; } } else { if (chdir(args[1]) ! 0) { perror(mysh: cd); return 1; } } return 0; }兩個容易忽略的細節(jié)第一cd不帶參數(shù)時應該回到HOME目錄。這是POSIX標準約定也是用戶在交互式Shell中的直覺。別嫌麻煩加上去。第二參數(shù)多于一個時怎么處理標準cd只接受一個參數(shù)加上可選的-P/-L標志。我們做個簡化版只取args[1]多余參數(shù)報錯即可。4.2exit的實現(xiàn)要有返回值意識int mysh_exit(char **args) { if (args[1] ! NULL) { // 如果帶了退出碼參數(shù)就解析它 int code atoi(args[1]); exit(code); } exit(0); }注意這里有個小訣竅你可以在主循環(huán)里讓run_builtin()返回一個特殊值提示“該退出Shell了”而不是在mysh_exit()里直接exit()。這樣設計更靈活以后你想加“退出前保存歷史記錄”“打印最后一條統(tǒng)計信息”之類的功能就還有機會攔截。直接exit()相當于把后門焊死了。4.3echo的一個隱藏問題參數(shù)已經(jīng)解析好了要不要處理引號echo在處理參數(shù)時要多個心眼。我們已經(jīng)說了第一版解析器不會處理引號所以用戶輸入echo hello world時parse_command()會拆成{echo, \hello, world\, NULL}。那echo打印出來就是hello world帶引號的兩個單詞。這是整個項目最折磨人的部分也最能體現(xiàn)“做玩具和做產(chǎn)品的差別”。如果我們想支持引號就得升級解析器讓它識別...內(nèi)的空格不算分隔符。但注意優(yōu)先級先讓核心跑起來再考慮完善。第一版的echo就是這么簡單int mysh_echo(char **args) { for (int i 1; args[i] ! NULL; i) { printf(%s, args[i]); if (args[i1] ! NULL) printf( ); } printf(\n); return 0; }等核心功能都跑通了你還想支持引號我們再單獨寫一個quote_aware_parse()替換掉parse_command()。這樣項目迭代順序清晰每一輪都有可驗證的成果。4.4 內(nèi)建命令的狀態(tài)管理用一個字符串數(shù)組和函數(shù)指針表內(nèi)建命令多了以后代碼別寫成一大串if-else。用表驅(qū)動的方法更清爽struct builtin_t { char *name; int (*func)(char **args); }; struct builtin_t builtins[] { {cd, mysh_cd}, {exit, mysh_exit}, {echo, mysh_echo}, {help, mysh_help}, // 可以自己加一個幫助命令 {NULL, NULL} }; int is_builtin(char *cmd) { for (int i 0; builtins[i].name ! NULL; i) { if (strcmp(cmd, builtins[i].name) 0) return 1; } return 0; } int run_builtin(char **args) { for (int i 0; builtins[i].name ! NULL; i) { if (strcmp(args[0], builtins[i].name) 0) { return builtins[i].func(args); } } fprintf(stderr, mysh: %s: not a builtin\n, args[0]); return 1; }以后想加pwd、export、history各自寫個函數(shù)然后在表里加一行就行主循環(huán)代碼一行不用改。代碼要寫到“加功能比加分支更容易”的程度這才叫好的項目結(jié)構(gòu)。5. 重定向與管道讓命令真正組合起來的Unix哲學外殼跑通了但現(xiàn)在的Shell是“單命令執(zhí)行器”。你沒法寫出ls out.txt也沒法寫出cat file | grep foo。這兩種操作涉及操作系統(tǒng)里最核心的一個概念文件描述符。5.1 文件描述符與重定向的底層原理一切都是文件Linux下“一切都是文件”進程通過文件描述符整數(shù)編號訪問文件。0號是標準輸入1號是標準輸出2號是標準錯誤。鍵盤輸入、屏幕輸出本質(zhì)上都是通過這幾個文件描述符完成的。ls out.txt的意思就是把1號文件描述符指向的文件換成out.txt。這樣ls寫往標準輸出的內(nèi)容就進了文件。實現(xiàn)用的系統(tǒng)調(diào)用是dup2()int fd open(out.txt, O_WRONLY | O_CREAT | O_TRUNC, 0644); dup2(fd, STDOUT_FILENO); // 把標準輸出重定向到 fd close(fd);dup2(fd, STDOUT_FILENO)的意思是“把fd復制到1號位置”即讓1號描述符指向fd指向的那個打開文件描述。之后printf輸出的內(nèi)容就去文件里了。注意dup2()之后必須close(fd)——因為1號和fd都指向同一個文件表項你只需要保留1號就夠了多一個引用只會造成資源泄漏。5.2 支持、、的解析三個運算符三種打開方式修改解析邏輯的步驟掃描args數(shù)組看有沒有、、或2之類的標記標記后面的那個參數(shù)就是文件名在子進程執(zhí)行execvp()之前先打開文件調(diào)用dup2()重定向然后執(zhí)行命令args里要把重定向操作符和文件名剔除只留下真正的命令參數(shù)。實現(xiàn)上我建議在run_external()里增加一個預處理步驟void run_external(char **args) { pid_t pid fork(); if (pid 0) { // 子進程 for (int i 0; args[i] ! NULL; i) { if (strcmp(args[i], ) 0) { int fd open(args[i1], O_WRONLY | O_CREAT | O_TRUNC, 0644); dup2(fd, STDOUT_FILENO); close(fd); args[i] NULL; // 截斷命令參數(shù) break; } // 同理處理 和 } execvp(args[0], args); perror(execvp); exit(EXIT_FAILURE); } // 父進程照舊 }有一個必須想清楚的細節(jié)為什么重定向在子進程里做而不在父進程里做因為在父進程里改文件描述符會影響到下一輪主循環(huán)而且重定向是“這一次命令”的行為不是Shell自己的行為。所以必須在fork()之后、execvp()之前在子進程內(nèi)部完成重定向——此時子進程有獨立的文件描述符表隨便改都不影響父進程Shell。用O_RDONLY用O_WRONLY | O_CREAT | O_APPEND。三個操作符映射到三種打開方式記住這個表就行。5.3 管道的實現(xiàn)|操作符的本質(zhì)是把一個進程的輸出接到另一個進程的輸入管道比重定向更微妙。ls | grep txt的邏輯是創(chuàng)建管道pipe()系統(tǒng)調(diào)用得到一個讀端和一個寫端ls的標準輸出重定向到寫端grep的標準輸入重定向到讀端兩個進程可以同時運行數(shù)據(jù)從ls流往grep。代碼實現(xiàn)void run_pipeline(char **left_args, char **right_args) { int pipefd[2]; pipe(pipefd); // pipefd[0] 讀端, pipefd[1] 寫端 pid_t p1 fork(); if (p1 0) { // 左命令輸出到寫端 close(pipefd[0]); // 用不到讀端 dup2(pipefd[1], STDOUT_FILENO); close(pipefd[1]); execvp(left_args[0], left_args); perror(execvp left); exit(EXIT_FAILURE); } pid_t p2 fork(); if (p2 0) { // 右命令從讀端讀入 close(pipefd[1]); // 用不到寫端 dup2(pipefd[0], STDIN_FILENO); close(pipefd[0]); execvp(right_args[0], right_args); perror(execvp right); exit(EXIT_FAILURE); } // 父進程關閉兩端 close(pipefd[0]); close(pipefd[1]); waitpid(p1, NULL, 0); waitpid(p2, NULL, 0); }這里有幾個反直覺的點我當年全踩過第一父子進程必須關掉沒用的一端。假設ls進程沒關讀端grep進程沒關寫端會發(fā)生什么管道還有“活著的引用”grep等待輸入時系統(tǒng)不會發(fā)EOF于是grep永遠等下去整個管道掛死。必須讓管道兩端的進程都關掉不需要的那一端才能保證數(shù)據(jù)流結(jié)束時有EOF信號。第二管道和重定向可以疊加嗎可以但順序很重要。ls | grep foo out.txt的結(jié)構(gòu)是“左命令輸出進管道右命令的輸出進文件”。實現(xiàn)時先按管道創(chuàng)建子進程然后在右子進程里先做標準輸入的重定向管道讀端再處理重定向。這個組合邏輯會越寫越復雜所以更優(yōu)雅的方案是逐步擴展成“命令表”command table結(jié)構(gòu)這里先不展開。第三管道的進程是同時還是先后創(chuàng)建記住一個原則先創(chuàng)建所有進程再等待所有進程。不要讓前一個進程先跑完再創(chuàng)建下一個——那樣的話數(shù)據(jù)還沒流到就關閉了而且會復制兩次fork()的環(huán)境效率更低。上面代碼先fork()左命令再fork()右命令兩個子進程都建好之后父進程統(tǒng)一waitpid()。5.4 關注點轉(zhuǎn)移管道實現(xiàn)中容易忽略的“僵尸進程”問題寫管道的時候有個概念你一定會遇到waitpid()的第二個參數(shù)status。我們說父進程“必須”調(diào)用waitpid()等待子進程但如果子進程是管道的一端你可能不知道應該等哪一個先結(jié)束。更隱蔽的問題如果父進程在waitpid(p1)上阻塞而p2已經(jīng)退出p2就變成了僵尸進程——它占著PID和進程表項只有父進程waitpid()收割它系統(tǒng)才會徹底回收。長期積累僵尸進程會耗盡系統(tǒng)進程表。所以更穩(wěn)妥的寫法是waitpid(p1, NULL, 0); waitpid(p2, NULL, 0);兩個都等待確保一個都不漏?；蛘哂脀ait(NULL)交替收割。這個細節(jié)在生產(chǎn)環(huán)境的Shell里是必須處理的但大多數(shù)教學代碼都會略過——我在這兒寫出來是希望你在做項目的時候主動去碰一碰這個問題。6. 交互體驗與常見坑提示符、輸入緩沖、CtrlC、歷史記錄項目做到這里已經(jīng)是個能用的Shell了。接下來這一節(jié)是純“從實戰(zhàn)中踩出來的經(jīng)驗”你在任何教科書上都不太容易湊齊這些細節(jié)但平時敲命令一定會遇到。6.1 提示符的學問交互模式下的fflush和顏色交互式Shell的提示符必須立即顯示。如果你用printf(mysh )標準輸出默認是行緩沖的——只有當遇到換行符或緩沖區(qū)滿才真正寫出去。提示符后面沒有換行所以你不fflush(stdout)的話用戶看到的就是一個干瞪眼的空白終端敲了命令才有反應。這個問題的表現(xiàn)很反直覺按回車之后提示符才出現(xiàn)又跟著你剛敲的命令終端顯示是亂序的。我第一版Shell就載在這里排查了半天還以為是多線程問題結(jié)果就是少了一行fflush。順帶一提給提示符加顏色會讓Shell看起來更友好但要注意非交互模式下不要用顏色。判斷方法很簡單Shell啟動時看isatty(STDIN_FILENO)是否為真。文件輸入或管道輸入時用了顏色反而要命。生產(chǎn)級Shell如Bash就是這么做的。6.2 信號處理為什么按CtrlC會退出你的Shell這是另一個大坑。默認情況下CtrlC會向前臺進程組發(fā)送SIGINT信號默認動作是終止進程。你的Shell如果沒做任何處理用戶在終端按CtrlCShell進程本身就會掛掉。你手寫的Shell必須自己處理SIGINT#include signal.h void handle_sigint(int sig) { printf(\n); fflush(stdout); } int main() { signal(SIGINT, handle_sigint); // ... 主循環(huán) }這樣用戶按CtrlC時Shell只是換個行、重新打印提示符而不是整個進程被殺掉。但注意子進程執(zhí)行期間按CtrlC信號會發(fā)給整個前臺進程組。你的Shell和子進程都在前臺需要決定是Shell處理還是子進程處理。更精細的做法是Shell忽略SIGINT而子進程保留默認行為。所以signal(SIGINT, SIG_IGN)放在 fork 之前的父進程里然后 fork 出來的子進程里再signal(SIGINT, SIG_DFL)恢復默認。這個細節(jié)跟真實Shell的行為一致你在Bash里跑sleep 10按CtrlC能殺掉sleep但Bash還活著。這里面的機制跑通之后你會對“進程組”和“信號傳遞”有更扎實的理解。6.3 歷史記錄用readline庫還是自己擼到了這一節(jié)你已經(jīng)實現(xiàn)了一個可以用于基本命令執(zhí)行、重定向、管道的Shell。如果還想加“上下鍵”翻歷史命令純粹靠自己寫會非常麻煩——因為全終端控制terminal raw mode的細節(jié)比你想的多得多。兩個選擇選擇一用 GNUreadline庫。這是最實際的選擇。它提供了readline()函數(shù)替代getline()并且自帶歷史記錄功能。代碼從char *line readline(mysh ); add_history(line);兩行就完成了。優(yōu)點顯而易見缺點是這個庫要額外鏈接依賴。教學演示項目可以不用靠近生產(chǎn)項目時值得引入。選擇二自己實現(xiàn)簡單的歷史記錄。如果你想鍛煉文件操作能力可以用一個數(shù)組存最近N條命令上下鍵通過終端原始模式讀入按鍵序列。這條路適合練手但“終端raw mode”會花掉你不少時間。我建議先把前述核心功能寫好、跑通歷史記錄用簡單數(shù)組版本即可——不要一上來就擼終端控制。6.4 一個容易被忽略的需求處理空命令和注釋符空行、只含空格的行、以#開頭的行應該被Shell跳過。這在腳本執(zhí)行場景下尤其重要因為腳本文件里經(jīng)常有空行和以#開頭的注釋。第一版可以先忽略但主循環(huán)里面對args[0] NULL的情況要直接continue。還有個細節(jié)把Shell的“退出碼”返回給操作系統(tǒng)。exit命令后你可以echo $?驗證退出碼是否正確。在主循環(huán)里每次執(zhí)行完外部命令從status里提取退出碼WEXITSTATUS(status)存到一個全局變量last_status里。后面實現(xiàn)、||或者$?變量時就靠這個值。7. 一個值得再走一遍的擴展清單這個項目能長成什么樣寫完核心Shell之后你可以繼續(xù)往這幾個方向擴展。這些擴展每一個都能單獨成文而且會逼你解鎖更多Linux機制。1. 通配符展開ls *.txt是怎么變成ls a.txt b.txt的你需要理解Shell的glob展開機制可以自己調(diào)用glob()函數(shù)實現(xiàn)也可以自己寫遞歸匹配。2. 環(huán)境變量賦值前綴VARvalue command這種寫法需要臨時修改子進程的環(huán)境變量。用setenv()在子進程內(nèi)部改但注意父進程環(huán)境不能變。3.$?特殊變量獲取上一條命令的退出碼。這個我們上面提過是通往條件執(zhí)行、||的第一塊磚。4. 作業(yè)控制CtrlZ暫停進程、jobs列出后臺任務、fg恢復前臺運行。這會把高深的前后臺進程組管理引入項目——做完包你理解“作業(yè)控制”是什么。5. 腳本執(zhí)行模式mysh script.sh從文件讀取命令執(zhí)行。這個做起來不難把getline的輸入源換成文件但會觸發(fā)一堆“是否打印提示符”等邊界判斷——跟真實Shell一致非交互模式不打印提示符。6. 引號處理完整支持單引號和雙引號。單引號內(nèi)一切字符按字面意義處理雙引號內(nèi)做變量替換。這需要把簡單的strsep解析器升級成帶狀態(tài)機的解析器。做完你就會明白為什么Shell的解析器一直是“復雜主題”。每做完一個擴展建議你做一個小對比用自己的Shell跑ls -l /tmp再去Bash里跑同樣的命令看看行為差異有多大。你會感受到從“模擬”到“理解”之間的距離。最后說一點個人體會。磨這個項目的時候我最深的感觸不是“哦原來Shell是這么工作的”而是“需要一個好用的測試工具”——自己寫Shell意味著你手里的每個命令都是被自己實現(xiàn)的代碼執(zhí)行的。當你發(fā)現(xiàn)自己寫的Shell居然能正確跑grep -r hello /usr/include | wc -l時那種“操作系統(tǒng)的拼圖在自己手里一塊塊拼上”的感覺特別踏實。而且這是一個適合長期維護的小項目。它不會太大但每次往里加一個功能、處理一個bug都能讓你對Linux的理解再深一圈。過三個月拿出來看看你會發(fā)現(xiàn)自己寫的代碼其實菜得不行——那恰恰說明你成長了。建議從今天開始動手先把3.3小節(jié)的parse_command()跑起來剩下的自然就有動力磨下去了。