从零写一个微型Shell：彻底搞懂进程控制

如果说Linux下哪个程序最能体现“进程控制”这四个字我第一个想到的肯定是Shell。你每天敲ls、cd、grep这些命令能跑起来背后全是fork、exec、wait这几个系统调用在忙碌。可大多数人用Shell用了几年却从来不知道它内部是怎么把命令变成进程的。我自己真正把Shell“吃透”不是靠看文档而是靠动手写了一个微型Shell。从那以后再看ps aux里的进程树看后台任务看管道和重定向思路完全不一样了。这篇博文我会从进程控制的底层机制讲起然后带你从零实现一个能运行外部命令、支持内建命令的微型Shell最后把管道、重定向这些进阶玩法也捋一遍。适合刚学完C语言、对Linux进程机制有基本概念但还想往深处走的读者。只要你能看懂fork函数的作用剩下就是跟着代码走一遍的事。1. 理解Shell的本质它不只是“命令解释器”1.1 我们每天都在用却很少琢磨Shell在做什么教科书上常说Shell是“命令解释器”这个说法没错但太抽象了。从进程的角度看Shell就是一个普通的用户态进程它一直在做一件事读取你输入的一行字符串拆成命令和参数然后创建新的进程去执行这个命令等命令跑完再回来读取下一行。这个循环听起来简单但里面藏着进程控制的全部核心逻辑。你输入的ls -lShell并不会自己去做目录列举它是找到一个叫/bin/ls的可执行文件创建一个子进程在子进程里把ls这个程序加载进来然后等待子进程退出。换句话说Shell是个“中间人”真正的活是子进程干的。想明白这一点你就理解了为什么进程控制是Shell的命脉。如果一个程序不能创建子进程不能加载新的可执行文件不能等待子进程结束那它就没有资格被称为Shell。1.2 为什么从进程控制切入很多人学Shell脚本一上来就背语法for循环怎么写、if判断怎么写、变量怎么引用这些当然重要。但如果你对底层进程机制没有概念遇到很多问题会一头雾水。比如ls | grep foo这个管道为什么左边命令的输出能直接变成右边命令的输入因为Shell在中间创建了一个管道文件把两个子进程的文件描述符接上了。又比如你在脚本里写sleep 100 为什么命令能跑到后台因为Shell fork出来的子进程没有被wait而且父进程先返回了提示符。再比如CtrlC为什么能终止正在运行的前台进程因为终端把中断信号发给了整个前台进程组Shell和它创建的子进程都收到了。这些现象表面上是Shell脚本的语法问题本质上全是进程控制的问题。从进程控制切入等于拿到了一把万能钥匙。1.3 自己写一个Shell到底能学到什么我当初写微型Shell最大的收获不是“我复刻了一个简陋的bash”而是把几个系统调用的关系彻底搞清楚了。fork复制进程exec替换进程映像wait回收子进程这三位一体构成了Unix进程模型的核心。再加上pipe、dup2、signal就能拼出管道、重定向、信号处理这些高级功能。自己实现一遍你还会深刻体会到为什么Unix的设计哲学是“一个程序只做一件事”。Shell只负责编排进程ls只负责列目录grep只负责过滤文本它们通过进程边界和文件描述符互相配合而不是把功能全塞进一个巨型程序里。这种设计思想不亲手写一个Shell很难有切身体会。2. 进程控制三基石fork、exec、wait2.1 fork进程复制与内存副本的真相fork大概是Unix里最特殊的系统调用因为它“调用一次返回两次”。在父进程里它返回子进程的PID在子进程里它返回0。这个特性经常把初学者绕晕但它的设计逻辑其实很朴素要创建一个新进程最直接的办法就是把当前进程完整复制一份让复制出来的进程去干活。复制到什么程度子进程拿到的是父进程内存空间的副本变量、栈、堆、文件描述符表全都有。这里的重点是“副本”也就是说父子进程的变量地址看起来一样但实际上是两块内存互相独立。子进程改一个变量父进程完全感知不到。这个机制在Shell里有个妙用fork之后子进程和父进程拥有相同的文件描述符表。所以子进程能继续使用Shell的标准输入、标准输出和标准错误。这就是为什么你敲命令命令的结果能直接显示在终端上不用额外传文件描述符。2.2 exec让子进程“换血”去干新活fork复制出来的子进程一开始和父进程跑的是同一份代码。如果就这么跑下去那Shell的子进程还在执行Shell的主循环没意义。所以fork之后要马上调用exec系列函数把当前进程的代码和数据整个替换成新的可执行文件。exec不是创建新进程它是在当前进程内“换血”。进程的PID不变文件描述符表默认也不变但代码段、数据段、堆、栈全被新程序覆盖。一旦exec成功它就不会返回因为原来的代码已经不存在了。如果它返回了那说明exec失败了比如你要执行的文件不存在、没有权限之类。exec系列函数有很多变体execl、execv、execle、execve等等其中日常用得最多的是execvp。它有两个好处第一个是自动在PATH环境变量里查找可执行文件不用你写完整路径第二个是自动把参数列表arrgv传进去和Shell的行为完全一致。2.3 wait父进程必须负起的收尸责任子进程退出了为什么父进程要关心因为子进程退出后不会立即消失它会变成一个“僵尸进程”占用内核进程表中的一条记录直到父进程调用wait或waitpid来读取它的退出状态。如果把系统比作一家公司那fork是招聘exec是给新人派活wait就是等人干完活之后回收工位。如果父进程一直不回收僵尸进程就会堆积。更严重的是如果父进程先于子进程退出子进程会被1号进程收养这又是另一种局面。Shell作为父进程必须老老实实等子进程退出用waitpid拿退出码。你平时在终端里敲命令Shell看起来像“卡住”了其实它就是在waitpid里等着呢。命令执行完Shell拿到退出码然后打印下一个提示符。2.4 一次命令执行背后的完整链路把三个系统调用串起来就是Shell执行一条外部命令的完整流程读取用户输入解析出命令名和参数。调用fork创建子进程。此时父子进程都在Shell的代码里。子进程调用execvp把自己换成要执行的命令程序父进程调用waitpid等待。子进程运行完毕waitpid返回Shell获得退出状态。回到主循环打印提示符读取下一条命令。这个流程里最容易犯的错误是顺序问题。一定要先fork然后在子进程里去exec父进程去wait。有人图省事想先exec再fork或者干脆不fork直接exec那Shell自己就被替换掉了彻底玩完。3. 微型Shell整体设计动手前先画好蓝图3.1 功能定位小而完整不求花哨写微型Shell之前先明确“微型”两个字的分寸。我的目标是让它能运行ls、grep、cat这类外部命令能处理带参数的命令能执行cd和exit这两个最基础的内建命令同时能正确处理退出状态。至于管道、重定向、通配符、变量展开、作业控制第一版先不做后面单独扩展。这样定位的考虑是麻雀虽小五脏俱全。这个范围刚好覆盖fork、exec、wait三个核心系统调用又不至于被细节淹没。管道和重定向虽然好玩但它们依赖的核心机制和主流程是同一个先跑通主干再贴枝叶。3.2 主循环流程拆解读入、解析、执行微型Shell的主循环本质上是个“读-解析-执行”的无限循环打印提示符比如mysh。读取一行输入用fgets从标准输入读。去掉字符串末尾的换行符。把字符串按空白字符分割成命令和参数数组。如果是空命令继续下一轮。如果命令是exit退出循环。如果命令是cd直接在当前进程里切换目录不走fork。如果是外部命令fork子进程子进程里execvp执行命令父进程waitpid等待。这个流程和bash的核心路径几乎一模一样只是bash处理了更多的语法糖。3.3 模块划分哪些函数该单独拎出来代码结构不用复杂但至少要分成两个函数一个是命令解析函数负责把字符串拆成argv数组另一个是命令执行函数负责处理内建命令和外部命令。主函数只管循环调用。特别提醒一点解析字符串的时候不要用strtok。这个函数内部用了静态变量保存状态不是线程安全的而且调用方式有点隐蔽容易踩坑。我选择手写一个简单的解析循环遇到空白字符就替换成\0遇到非空白字符就记为参数起始位置。代码量不大但逻辑清楚后续要扩展引号支持也方便。4. 代码实现从零写一个微型Shell4.1 第一步提示符与输入读取先写一个主循环的骨架能读输入能打印提示符但还什么都不干#include stdio.h #include stdlib.h #include string.h #include unistd.h #include sys/wait.h #define MAXLINE 1024 #define MAXARGS 64 int main(void) { char line[MAXLINE]; while (1) { printf(mysh ); fflush(stdout); if (fgets(line, MAXLINE, stdin) NULL) { printf(\n); break; } // 先只打印出来验证读取正常 printf(你输入的是: %s, line); } return 0; }这里有个非常容易踩的坑printf(mysh )后面必须加fflush(stdout)。因为stdout默认是行缓冲模式没有换行符的话提示符可能不会立即显示你会看到屏幕上什么都没有以为程序卡死了。我第一次写的时候就被这个坑恶心得不行加上fflush之后才一切正常。4.2 第二步手写解析器拆分命令接下来写解析函数把一行字符串拆成argv数组void parse_command(char *line, char **argv) { while (*line ! \0) { // 跳过空白字符并把它们替换为字符串结束符 while (*line || *line \t) { *line \0; } // 如果当前位置不是结束符说明是一个参数的开头 if (*line ! \0) { *argv line; // 跳过这个参数直到遇到空白或结束 while (*line ! \0 *line ! *line ! \t) { line; } } } *argv NULL; }这段代码的思路是遍历字符串把空白字符全部替换成\0这样每个参数就变成了独立的字符串argv数组里的每个指针指向这些字符串的开头。注意*argv line这行的逻辑先把当前指针存入argv再把argv向后移动。在主循环里调用它顺便处理空行char *argv[MAXARGS]; // 去掉换行符 line[strcspn(line, \n)] \0; if (line[0] \0) { continue; } parse_command(line, argv);去掉换行符这步也很关键。fgets会把换行符读进来如果不处理解析出来的最后一个参数后面会跟着一个\n执行命令的时候就会找不到文件。这里用strcspn(line, \n)找到换行符的位置然后直接置零。4.3 第三步用execvp执行外部命令解析完成后判断一下argv[0]是不是空。如果不是并且不是内建命令就走外部命令执行流程pid_t pid fork(); if (pid 0) { perror(fork); continue; } else if (pid 0) { // 子进程 execvp(argv[0], argv); // execvp失败了才会走到这里 perror(argv[0]); exit(127); } else { // 父进程 int status; waitpid(pid, status, 0); }注意这里有两个细节。第一execvp的第二个参数是argv数组它的第0个元素是命令名最后一个元素是NULL这个格式和main函数接收的argv完全一致。第二子进程里execvp如果失败了一定要exit否则子进程会继续执行Shell的主循环变成两个Shell抢输入场面极其混乱。exit(127)这个退出码不是随便定的bash约定127表示“命令未找到”沿用这个约定测试的时候用echo $?就能验证退出码是否正确。4.4 第四步实现cd和exit两个内建命令内建命令不能走fork因为cd需要改变Shell自身的当前工作目录。如果fork一个子进程去执行chdir那只是改子进程的目录对Shell本身毫无影响跑完子进程就没了目录切换了个寂寞。所以cd的执行代码要放在主循环里在当前进程直接调用chdirif (strcmp(argv[0], exit) 0) { break; } if (strcmp(argv[0], cd) 0) { if (argv[1] NULL) { fprintf(stderr, cd: 缺少参数\n); } else if (chdir(argv[1]) ! 0) { perror(cd); } continue; }exit就简单了直接break跳出循环。理论上可以接收一个退出码参数但第一版先不做写死返回0也是可以的。我把cd和exit的判断放在外部命令逻辑之前因为这两种情况根本不进入fork流程。判断的顺序不要搞反先把内建命令处理完剩下的全都当成外部命令走fork。4.5 完整代码一个能跑的微型Shell把所有代码拼起来就是一个完整的微型Shell#include stdio.h #include stdlib.h #include string.h #include unistd.h #include sys/wait.h #define MAXLINE 1024 #define MAXARGS 64 void parse_command(char *line, char **argv) { while (*line ! \0) { while (*line || *line \t) { *line \0; } if (*line ! \0) { *argv line; while (*line ! \0 *line ! *line ! \t) { line; } } } *argv NULL; } int main(void) { char line[MAXLINE]; char *argv[MAXARGS]; while (1) { printf(mysh ); fflush(stdout); if (fgets(line, MAXLINE, stdin) NULL) { printf(\n); break; } line[strcspn(line, \n)] \0; if (line[0] \0) { continue; } parse_command(line, argv); if (argv[0] NULL) { continue; } if (strcmp(argv[0], exit) 0) { break; } if (strcmp(argv[0], cd) 0) { if (argv[1] NULL) { fprintf(stderr, cd: 缺少参数\n); } else if (chdir(argv[1]) ! 0) { perror(cd); } continue; } pid_t pid fork(); if (pid 0) { perror(fork); continue; } else if (pid 0) { execvp(argv[0], argv); perror(argv[0]); exit(127); } else { int status; waitpid(pid, status, 0); } } return 0; }编译运行一下gcc -o mysh mysh.c ./mysh然后你就可以在mysh提示符下执行ls、pwd、grep root /etc/passwd这些命令了。那种“命令真的是我fork出来的进程跑出来的”感觉和用bash完全不一样。5. 实操中踩过的坑与解决心得5.1 换行符的坑fgets带来的错觉fgets读取输入时会把\n也读进缓冲区如果不去掉解析出来的最后一个参数就带着换行符。比如你输入ls -l解析结果是ls和-l\nexecvp去查找名为-l\n的文件当然找不到。解决方法是line[strcspn(line, \n)] \0。这个写法简洁通用比手动遍历找\n省事。我见过有人用line[strlen(line)-1] \0但如果fgets因为文件结束而只返回部分内容或者输入为空字符串strlen返回0就会越界访问。strcspn版本更安全无论什么情况都不会越界。5.2 提示符不显示缓冲区在捣乱“程序好像卡住了”这类问题十有八九是缓冲区问题。printf(mysh )没有换行符数据先留在用户态的缓冲区里没有刷到终端。只有遇到换行符、缓冲区满、或者程序退出时才会刷出来。加一行fflush(stdout)就解决了。这个坑其实很能说明问题Shell是个交互式程序它要时刻保证“输出立即可见”不能依赖默认缓冲策略。很多网络服务也有类似的“行缓冲变全缓冲”问题比如printf输出被重定向到文件时缓冲策略可能变成全缓冲不及时fflush就什么都写不进去。5.3 僵尸进程wait没做好会怎样我最初写微型Shell时故意把waitpid那行去掉试了试。执行完几条命令后打开另一个终端跑ps -ef果然看到一堆defunct进程这就是僵尸进程。僵尸进程是已经退出、但还没被父进程回收状态的进程。它不占用CPU和内存但会占用内核进程表项。进程表项是有限的如果一直不回收积累多了会导致系统无法创建新进程。所以在fork之后父进程一定要调用waitpid这是“收尸”更是系统资源管理的基本要求。waitpid的第三个参数0表示阻塞等待也就是父进程在这里等着直到指定子进程退出。如果你想让父进程不阻塞可以用WNOHANG选项配合循环检查这就是后面做作业控制的基础。5.4 Ctrl-C把Shell一起干掉信号的继承问题写完微型Shell你兴奋地在里面跑一个sleep 100然后按CtrlC结果发现不仅sleep被终止了微型Shell也跟着退出了。这是为什么因为终端产生的中断信号SIGINT会发给前台进程组里的所有进程包括Shell和它创建的子进程。我们的Shell没有处理SIGINT默认动作就是终止进程所以父子一起凉。bash是怎么处理的bash会忽略SIGINT同时让前台子进程恢复默认处理。实现思路是父进程里把SIGINT设置为忽略fork之后子进程把SIGINT恢复为默认再exec新程序。这样CtrlC只影响正在运行的前台命令Shell自己安然无恙。核心代码是这样signal(SIGINT, SIG_IGN); // Shell忽略SIGINT pid_t pid fork(); if (pid 0) { signal(SIGINT, SIG_DFL); // 子进程恢复默认处理 execvp(argv[0], argv); perror(argv[0]); exit(127); }这个“父进程忽略、子进程恢复默认”的模式在写任何信号相关的服务程序时都很重要。信号处理有个特点忽略信号的行为会被fork和exec继承但自定义的信号处理函数在exec之后会被重置为默认。这个继承规则搞清楚了信号问题基本就解决了一大半。5.5 exec之后子进程“赖着不走”的隐患再强调一次execvp失败后的exit。如果不写子进程的execvp失败了会继续执行主循环代码打印提示符再读一次输入。这时你的终端里可能出现两个Shell在抢输入输入ls就会执行两次排查起来非常痛苦。我在代码里把perror(argv[0])和exit(127)放在一起就是要确保子进程失败后立刻退出。perror会打印类似ls: No such file or directory的信息把错误原因展示给用户。别小看这几行它们决定了你的Shell在出错时是优雅报错还是彻底崩溃。6. 从微型走向实用管道、重定向与作业控制6.1 管道让进程之间真正说上话管道在Shell里太常见了ps aux | grep nginx随手就写。管道本质上是内核提供的一段缓冲区有两个文件描述符一个写端、一个读端。Shell要做的就是把左边命令的标准输出接到写端把右边命令的标准输入接到读端。流程可以拆成这样用pipe()创建管道得到两个文件描述符pipefd[0]读端和pipefd[1]写端。fork第一个子进程让它执行左边命令。在子进程里把标准输出STDOUT_FILENO重定向到pipefd[1]关闭不需要的读端然后execvp。fork第二个子进程让它执行右边命令。在子进程里把标准输入STDIN_FILENO重定向到pipefd[0]关闭不需要的写端然后execvp。父进程关闭两个管道描述符分别等待两个子进程结束。关键代码片段int pipefd[2]; if (pipe(pipefd) 0) { perror(pipe); return; } if (fork() 0) { // 左命令: 输出到管道写端 dup2(pipefd[1], STDOUT_FILENO); close(pipefd[0]); close(pipefd[1]); execvp(cmd1[0], cmd1); perror(cmd1[0]); exit(127); } if (fork() 0) { // 右命令: 从管道读端输入 dup2(pipefd[0], STDIN_FILENO); close(pipefd[0]); close(pipefd[1]); execvp(cmd2[0], cmd2); perror(cmd2[0]); exit(127); } close(pipefd[0]); close(pipefd[1]); wait(NULL); wait(NULL);dup2的作用是把旧描述符复制到新描述符上然后关闭旧描述符。这行代码的本质是“把标准输出变成管道的写端”从这以后子进程里任何往stdout写的数据都会进入管道。父进程为什么要关闭两个管道描述符因为如果不关父进程自己还持有写端和读端。比如父进程持有写端右边命令读完管道后可能不会收到EOF因为管道还有一个写端是开着的它会一直等待。这个细节非常关键很多人的管道实现半天读不到EOF就是因为某个进程没关闭多余的描述符。6.2 重定向文件描述符的魔法重定向和管道本质上是同一件事都是通过dup2把标准输入或输出指向别的地方。 file就是把标准输出指向文件 file就是把标准输入指向文件。思路很简单int fd open(output.txt, O_WRONLY | O_CREAT | O_TRUNC, 0644); dup2(fd, STDOUT_FILENO); close(fd); // 之后execvp命令的输出就写进文件了这里要注意三个打开标志的组合O_WRONLY表示只写O_CREAT表示文件不存在就创建O_TRUNC表示已有内容清空。如果要支持追加模式用O_APPEND代替O_TRUNC。把重定向、管道和命令解析结合起来你就离一个真正实用的Shell不远了。命令解析时需要识别|、、这些特殊字符把它们从普通参数里分离出来然后决定创建管道还是打开文件。这一步的工作量比想象中大因为要考虑cmd file和cmd1 | cmd2 file这种组合情况。我的建议是先解析出管道分割的多个命令段再在每个命令段内处理重定向一层层剥。6.3 作业控制加一个Ctrl-Z试试作业控制是Shell里面比较高级的主题涉及进程组、会话、终端控制等概念。当你按下CtrlZ前台子进程收到SIGTSTP信号暂停Shell打印出作业编号回到提示符。jobs查看作业列表fg把作业调回前台bg让作业在后台继续运行。实现作业控制的关键是setpgid和tcsetpgrp。setpgid用来设置进程组IDtcsetpgrp用来设置终端的前台进程组。Shell本身属于一个进程组前台运行的子进程应该被放到一个新的进程组成为前台进程组这样终端信号才能只发给它。说实话作业控制我第一次写的时候折腾了两三天才跑通。它比管道和重定向复杂得多因为进程组和终端交互的细节非常繁琐。但如果你能完整实现一个支持CtrlZ、jobs、fg、bg的微型Shell你对Unix进程模型的理解基本就到“熟练工”水平了。回头看看从打印一行提示符开始到能执行外部命令再到管道、重定向、作业控制这条路恰好复现了Unix Shell几十年来的演进路径。我自己写这个微型Shell的最大体会是很多概念比如进程、文件描述符、信号看文档的时候觉得都懂但真正写代码时发现满眼都是“为什么这里不行”“为什么那里会卡住”。这些卡住的地方恰恰是你认知的盲区。把这个小小的Shell从“能跑”一步步改成“好用”你会变成一个真正理解Linux进程的人。