从零手写Linux Shell：命令行解释器的原理与实现

在Linux下用命令行的人，大多对Shell既熟悉又陌生。熟悉的是每天敲ls、cd、grep这些指令，陌生的是这个“命令行解释器”到底是怎么把一行字符变成一个个进程的。我自己动手做了一个自定义Shell之后，才真正把这条链路看清楚：从键盘读入字符串，按规则解析成命令和参数，去PATH目录里找到可执行文件，然后fork出子进程加载执行，再回收它的退出状态。这篇文章会把我从零实现一个可用Shell的全过程、设计取舍、踩坑记录都摊开来讲，对准备Linux面试的同学和想深入理解进程机制的开发者都有参考价值。

1. 项目背景：为什么值得自己写一个Shell

1.1 Shell是什么，命令行解释器在做什么

Shell这个词，日常对话里通常指的是那个黑底白字的终端窗口。但严格说，窗口只是终端模拟器，真正执行命令解释工作的是一个叫Shell的程序，最常见的是bash、zsh，它们本质上都是一个命令行解释器。它的核心任务就是反复执行一套循环：把用户输入的一行文本读进来，识别出命令名和参数，然后去操作系统里找到对应的程序，创建子进程去运行它，最后把运行结果反馈给用户。

我拿一条实际命令举例。你输入grep error /var/log/syslog | less时，Shell做的事情远超你看到的表象。它要按管道符把这一个命令行拆成两段，分别创建两个子进程，前一个进程的stdout被连接到后一个进程的stdin，再等待两者结束。整个过程中，Shell自己始终待命，不会退出，然后等你输入下一条命令。理解这个循环，就理解了Shell的一切。

1.2 自定义Shell的核心价值与应用场景

有人可能会问，bash不是现成的吗，自己写一个Shell有什么意义？意义在于，它是把操作系统理论知识转化成动手能力的最佳训练场之一。fork、exec、waitpid、pipe、dup2这些系统调用，你单独学每一个都能看懂，但只有组合在一起做一个真实项目，你才会发现它们的边界条件和协作方式。比如fork之后父子进程各自执行到哪里，管道文件描述符在哪边关闭才合适，信号处理是怎么从父进程传给子进程的。

这个项目的适用人群很明确。如果你正准备Linux方向的面试，这是很常见的编程题，面试官可能直接让你30分钟手写一个能执行ls、cd的简化版Shell，考察你对进程管理和字符串解析的掌握程度。如果你是后端工程师，日常要写脚本、排查启动脚本问题，理解Shell的执行模型会让你定位问题更快。嵌入式Linux开发者同样会受益，很多板子上的init脚本、工具链配置都依赖Shell逻辑。

我自己做这个项目还有一个私心：想弄明白为什么网上那些Shell脚本偶尔会出现让人摸不着头脑的行为。答案其实都藏在解释器的工作方式里，比如变量展开的时机、子Shell的边界、内建命令与外部命令的区别。把这些搞定了，写脚本的功力也会上一个台阶。

2. 整体架构设计：从最朴素的循环开始

2.1 主循环：读入、解析、执行、回到读入

任何Shell都逃不过一个主循环，学术上叫REPL（Read-Eval-Print Loop），翻译过来就是“读入-求值-打印-循环”。虽然你看到的bash功能丰富，但它的骨干就是这个循环。自定义Shell的主循环大概长这样：

1. 打印提示符，比如mysh$，然后等待输入
2. 读取一行字符串
3. 解析这一行，得到命令名和参数列表
4. 如果是内建命令（cd、exit等），直接在当前进程内处理
5. 如果是外部命令，fork一个子进程，在子进程里exec目标程序
6. 父进程waitpid等待子进程结束，然后回到第1步

为什么是这样一个结构？因为Shell的本质是一个交互式的命令分发器，它自己不做具体的“干活”，而是把活派发给子进程。父进程不清场、不替换，始终保持Shell自身的身份，这样用户才能在一个会话里连续敲很多条命令。刚开始写的时候，我建议先把这个循环用最简单的printf和字符串分割搭出来，哪怕不处理管道，先把“能跑通一条命令”这个目标实现，成就感来得快，后面扩展也自然。

2.2 模块划分：避免把代码堆成一个main函数

很多人写自定义Shell，习惯把输入、解析、执行全部堆在main里，几百行写下来，自己都找不到北。我强烈建议按职责拆模块，哪怕每个模块只是一个函数，也要让它们在逻辑上独立。我自己的划分是这样的：

• 输入模块：read_line()，负责读一行、去掉末尾换行符
• 解析模块：parse_cmdline()，把一行文本拆成argv数组
• 执行模块：execute_external()，做fork/exec/wait的完整流程
• 内建命令模块：run_builtin()，处理cd、exit、pwd等
• 工具模块：错误打印、内存释放等公共逻辑

拆开之后有个明显的好处：你可以给解析模块单独写测试。比如我建过一个临时main函数，往解析器里塞" ls -l /tmp "、连续tab、空字符串这些边界输入，直接观察argv数组是否正确。如果没有模块划分，这种测试根本无处着手。在项目后期，每当出现诡异问题，也是按模块逐个排查，效率高很多。

2.3 数据结构设计：用一张结构体承接解析结果

解析结果最好用一个结构体来封装，别用一堆裸指针手忙脚乱地传来传去。我用的结构体很简单：

#define MAX_ARGS 64 typedef struct { char *args[MAX_ARGS]; int argc; } cmdline_t;

args[0]是命令名，args[1]到args[argc-1]是参数，最后一个位置置NULL以兼容execvp的结束标志需求。使用结构体的优势在于，后续扩展管道和重定向时，你只需要在结构体里追加字段，比如const char *in_file、const char *out_file、int pipe_to_next等等，解析函数就可以一次性把所有信息装配好，执行函数只需要读取这些字段做决策。

这里我还想强调一个解析时的通病：很多人会用strtok直接分割。strtok用起来确实简单，但它会把原始字符串改写得面目全非，并且内部维护一个静态指针，不支持嵌套使用和多线程。如果后面想处理引号、通配符，strtok的模型会让你很难受。我是建议手写一个轻量分割函数，也不难，本质就是遍历一遍、跳过空白、填充指针。

3. 核心实现：命令解析与程序执行

3.1 读取输入：getline与fgets的选择

读取用户输入，我第一个建议是直接用POSIX的getline函数。它会自动分配缓冲区，越读越长的行也不怕，返回值是读取的字节数，出错或读到EOF时返回-1。一个最简单的读取代码如下：

char *line = NULL; size_t bufsize = 0; ssize_t nread; printf("mysh$ "); fflush(stdout); nread = getline(&line, &bufsize, stdin); if (nread == -1) { free(line); break; } if (nread > 0 && line[nread - 1] == '\n') { line[nread - 1] = '\0'; }

有两个极易踩的坑。第一个是提示符不显示的问题：printf("mysh$ ")后，如果缺了fflush(stdout)，提示符可能停留在缓冲里没刷到屏幕，用户看到的是一片空白的等待。第二个是getline返回EOF的问题：在终端里按Ctrl+D表示输入结束，此时getline返回-1，Shell应该把这个当作退出信号，如果不做处理，程序会陷入死循环。处理完换行符也很重要，否则执行时会把换行符当成命令名的一部分。

3.2 解析输入：自己动手分割，别让strtok背锅

解析这步，我认为是整个项目的兵家必争之地。一个健壮的解析器要能处理：行首行尾的多余空格、行中间的连续空白、输入为空、只输入空白字符、带tab分隔符的情况。下面这个功能是我一直使用的模板：

void parse_cmdline(char *line, cmdline_t *cmd) { char *p = line; int pos = 0; cmd->argc = 0; while (*p) { while (*p && isspace((unsigned char)*p)) p++; if (!*p) break; if (pos >= MAX_ARGS - 1) break; cmd->args[pos++] = p; while (*p && !isspace((unsigned char)*p)) p++; if (*p) { *p = '\0'; p++; } } cmd->args[pos] = NULL; cmd->argc = pos; }

你要注意这个函数是在“原地”修改了line字符串，把分割点处的空白替换成了\0，然后用指针记录每个参数段的起始位置。好处是不用额外分配每段的空间，执行完毕后统一释放line本身即可。代价是解析后的line字符串生命周期必须持续到命令执行结束，这在Shell里是天然的。

对于不熟悉指针操作的朋友，我再举个例子。输入ls -l /tmp，line的内容就是ls空格-l空格/tmp这串字符。第一轮循环，p从l开始，记录args[0]指向l，然后扫到减号和l，遇到空格，把那个空格改成'\0'，此时args[0]的内容就是ls；第二轮循环p跳过空格来到了减号，记录args[1]指向减号……以此类推，最后得到的args数组就是{"ls", "-l", "/tmp", NULL}。把字符串拆解这个基本功打牢，后续解析重定向符号、管道符都会顺手很多。

3.3 进程创建三件套：fork、exec、waitpid

这段是整个Shell的心脏。在Linux中，创建新进程的唯一方式就是fork，它会复制调用进程的地址空间、文件描述符表和各种属性，返回两次：在父进程中返回子进程的PID，在子进程中返回0，失败时返回-1。之后子进程去调用exec族函数，把自己的地址空间整体替换成目标程序，这期间PID是不变的。

一个标准的外部命令执行流程如下：

pid_t pid = fork(); if (pid < 0) { perror("fork failed"); return; } if (pid == 0) { // 子进程 execvp(cmd->args[0], cmd->args); fprintf(stderr, "mysh: %s: command not found\n", cmd->args[0]); exit(EXIT_FAILURE); } else { // 父进程，等待子进程退出 int status; waitpid(pid, &status, 0); }

这里的每个细节都值得抠。第一，fork返回之后，父子进程都会从fork的下一行继续执行，所以必须用if对返回值做一个分叉，否则同一份代码会在父子进程里各跑一遍。第二，execvp自带PATH搜索能力，它会在PATH环境变量指示的每个目录里依次找可执行文件，找到后加载运行；如果你想手动实现PATH搜索逻辑，可以拆开PATH字符串逐个目录stat检查，但那其实是在重复造轮子，标准场景交给execvp就够了。第三，子进程在执行execvp之前，如果前面的初始化逻辑失败需要报错退出，记得一定要调用exit，而不是return，不然它就会跑回Shell的主循环。

waitpid在这里的作用是让父进程把子进程的资源回收掉。如果不回收，子进程变成僵尸进程，长期霸占PID条目。在Shell这个场景，waitpid(pid, &status, 0)是阻塞式的，让Shell停下来等命令执行完，这符合交互式终端的预期。如果你以后做后台任务（命令后面加&），就不能阻塞等待了，需要改用WNOHANG选项配合SIGCHLD信号。

3.4 内建命令：为什么cd必须由Shell自己执行

我前面强调过，Shell在执行外部命令时是通过fork子进程来实现的。但有些命令根本不能fork，最典型的就是cd。因为目录是进程的属性，每个进程有自己的当前工作目录。如果你在子进程里执行chdir，它改变的只是那个临时子进程的工作目录，子进程退出后就什么都留不下，Shell的目录还是原地不动。这就是cd必须是内建命令的根本原因。

实现内建命令的常见姿势是一张查找表加一个分发函数。我这边用的是最简单的if-else链：

int run_builtin(cmdline_t *cmd) { if (strcmp(cmd->args[0], "exit") == 0) { exit(cmd->argc > 1 ? atoi(cmd->args[1]) : 0); } else if (strcmp(cmd->args[0], "cd") == 0) { const char *target = cmd->argc > 1 ? cmd->args[1] : getenv("HOME"); if (target == NULL) target = "/"; if (chdir(target) != 0) { perror("cd"); } } else if (strcmp(cmd->args[0], "pwd") == 0) { char buf[PATH_MAX]; if (getcwd(buf, sizeof(buf)) != NULL) { printf("%s\n", buf); } } else { return 0; // 不是内建命令，交给外部执行 } return 1; }

我建议exit支持参数，比如exit 3可以直接退出并返回指定状态码，这在脚本环境测试时很有用。cd不带参数时的默认行为是回到HOME，你可以用getenv("HOME")来实现，注意处理getenv返回NULL的极端情况。另外，pwd也可以用getpwuid或者读取环境变量PWD，但最稳妥的还是getcwd，毕竟它是内核层面的准确值。

3.5 错误处理：命令找不到与空命令的边界

Shell的命令行解释器面对的输入五花八门，出错处理做得不好，很容易影响交互体验。第一条要处理的是空命令。用户在提示符下直接按了回车，或者输入了一堆空格，解析结果会是argc为0。此时Shell应该退回到读取状态，什么也不执行，而不是把空字符串当成命令去exec。

第二条要处理的是命令找不到。外部命令exec失败时，父进程只能通过子进程的退出状态间接知道这件事。我建议在子进程里打印明确的错误信息，格式可以模仿bash的风格，比如：

fprintf(stderr, "mysh: %s: command not found\n", cmd->args[0]);

这里面的mysh是我自定义Shell的名字，这样用户看到错误提示时能区分是哪个程序输出的。注意错误信息要打到stderr，因为用户完全可能执行了somecmd > output.txt，如果错误信息打到stdout，就会混进输出文件里，用户根本看不到。

还有个隐藏的坑：如果用户在命令行里输入了纯空白的字符串，解析后虽然argc是0，但分配的内存还是需要释放的。我在主循环里统一用free(line)处理，保证内存不泄漏。别小看泄漏，Shell是长期运行的交互程序，每次命令泄漏一点点，累积到几千条命令后内存占用会非常难看。

4. 进阶特性：管道、重定向与信号处理

4.1 管道实现：把上一个命令的输出灌进下一个命令的输入

管道是Shell的经典杀手锏。在bash里输入cat access.log | grep 404 | wc -l这种多级管道时，Shell要把三个进程串成一条数据流水线。我先说最简单的两级管道，理解了它，多级只是重复这个模式。

pipe系统调用会创建一对文件描述符，pipefd[0]负责读，pipefd[1]负责写，写入写端的数据会从读端读出来。管道本质上是内核里的一块缓冲区，一端生产一端消费。要执行cmd1 | cmd2，关键是把cmd1的stdout重定向到管道的写端，把cmd2的stdin重定向到管道的读端，具体流程是：

1. int pipefd[2]; pipe(pipefd);
2. fork出第一个子进程，在子进程里dup2(pipefd[1], STDOUT_FILENO)，然后exec cmd1
3. fork出第二个子进程，在子进程里dup2(pipefd[0], STDIN_FILENO)，然后exec cmd2
4. 父进程里马上把pipefd[0]和pipefd[1]都close掉，然后wait两个子进程

这里面的门道全在“什么时候关闭文件描述符”上。管道要读到EOF，必须满足“所有写端的复制都已关闭”这个条件。父进程持有pipefd[1]的副本不关，cmd2读数据时永远等不到文件结束信号，read系统调用会一直阻塞，表现出来就是命令挂起，整个Shell像死了一样。这个坑我踩过不止一次，建议在代码里用注释明确标注每个fd的持有者是谁，该谁关就谁关。

4.2 重定向实现：dup2把标准流换成文件

管道的本质其实也是一种重定向，只是目标换成了另一个进程的文件描述符。命令行的>、<重定向则是把标准流换成一个文件。以ls > out.txt为例，在子进程里做三步：

int fd = open("out.txt", O_WRONLY | O_CREAT | O_TRUNC, 0644); if (fd < 0) { perror("open"); exit(EXIT_FAILURE); } dup2(fd, STDOUT_FILENO); close(fd); // 然后exec ls

为什么重定向必须在子进程做而不是父进程做？因为标准输出文件描述符在Shell进程里是它自己打印提示符、打印错误信息的通道。如果在父进程里把STDOUT_FILENO整个替换成文件，那Shell后续所有输出都会写进文件，终端上连提示符都看不到，这显然不可接受。所以正确逻辑是：父进程检测到命令行里带重定向符号时，把“要打开哪个文件、用什么方式打开”的信息记录在cmdline_t结构体里，fork出子进程后，子进程再去执行open/dup2/close，替换自己的标准流，然后exec。

再补充一个容易出错的地方：输出重定向的open标志组合。>对应O_WRONLY|O_CREAT|O_TRUNC，覆盖写；>>对应O_WRONLY|O_CREAT|O_APPEND，追加写；<对应O_RDONLY。如果你忘记O_CREAT，目标文件不存在时open直接失败；如果你把O_TRUNC和O_APPEND混用，那语义就乱套了。我在项目里专门用枚举定义了重定向类型，避免手写标志组合出错。

4.3 信号处理：让Ctrl+C正常地只杀掉子进程

交互式Shell对信号的处理是用户体验的重要一环。在终端里按Ctrl+C，内核会向前台进程组发送SIGINT信号。如果Shell自己不忽略这个信号，那么按下Ctrl+C的一瞬间，Shell和正在运行的子进程会同时收到SIGINT，结果命令没跑完，Shell自己也被信号中断退出了，这显然不是用户期望的行为。用户期望的是“中断当前命令，但Shell保持存活”。

所以Shell的处理策略是：它自己忽略SIGINT，但在子进程里恢复SIGINT的默认行为，这样Ctrl+C只会命中正在执行的前台命令子进程。

// 父进程里 signal(SIGINT, SIG_IGN); // fork后、exec前，在子进程里 signal(SIGINT, SIG_DFL);

有人会问，为什么子进程需要重新设置？因为fork会把父进程的信号处理设置继承下去，如果不恢复默认，子进程也会忽略SIGINT，那Ctrl+C连子进程也杀不死了，命令无法被中断。理解了信号处理的继承机制，这个问题就迎刃而解。

除了SIGINT，SIGCHLD也值得关注。当子进程退出时，内核会向父进程发送SIGCHLD信号，如果父进程不接收，也不waitpid，子进程退出后就成了僵尸。在支持后台任务的情况下，你不可能时刻阻塞等待每一个子进程，所以常见的做法是捕获SIGCHLD，在信号处理函数里循环调用waitpid(-1, &status, WNOHANG)，把已经退出的子进程全部回收掉。

5. 完整代码框架与常见问题排查实录

5.1 最小可运行Shell的骨架结构

把前面讲到的模块串起来，一个功能基础但能完整运行的Shell骨架是这样：

int main(void) { signal(SIGINT, SIG_IGN); while (1) { printf("mysh$ "); fflush(stdout); char *line = NULL; size_t bufsize = 0; ssize_t nread = getline(&line, &bufsize, stdin); if (nread == -1) { free(line); break; } if (line[nread - 1] == '\n') line[nread - 1] = '\0'; cmdline_t cmd; parse_cmdline(line, &cmd); if (cmd.argc == 0) { free(line); continue; } if (run_builtin(&cmd) == 0) { execute_external(&cmd); } free(line); } return 0; }

这个骨架里没有任何炫技，但每一步都是必需的。signal放在主循环外统一设置，避免每轮重复。getline返回-1时退出循环，这就是Ctrl+D退出Shell的原理。argc为0时先释放再continue，这是空命令的安全处理。run_builtin返回1表示命令已被内建处理，返回0表示需要外部执行。

拿到这个骨架后，我建议你按这样的顺序迭代：

1. 先只实现外部命令的fork/exec/wait，保证ls、pwd、date能跑
2. 再加入内建命令cd、exit
3. 再加单个重定向，测试>、<
4. 再加入单级管道，测试cmd1 | cmd2
5. 最后考虑多级管道和信号细节

每完成一步就编译运行测试，不要试图一次写完所有功能再调试。我说实话，自己第一次尝试时上来就写多级管道，结果一堆fd管理问题纠缠在一起，调试痛苦得不行。分步迭代是最省心的路径。

5.2 常见问题速查表：我踩过的那些坑

我把实现过程中遇到的高频问题整理成速查表，希望对你有用：

这张表里的每一行我都实际遭遇过。尤其是“出两条提示符”这个问题，当时排查了很久，最后发现问题在exec失败后少写了exit——子进程从exec调用的下一行继续执行，而我的代码在那里没有退出，它就直接循环回了主循环，开始打印提示符读输入，看上去就像Shell出现了两个实例。

5.3 调试技巧与踩坑心得

调试自定义Shell，我强烈推荐用strace。运行strace -f -o /tmp/trace.txt ./mysh，然后在里面执行一条命令，比如ls -l /tmp，查看跟踪文件里有关fork、execve、open、dup2、wait4的系统调用序列。你可以非常直观地看到子进程exec的是哪个路径、重定向是否生效、哪个fd被关闭了。这种系统调用级别的日志，是你自己加打印日志可能漏掉的。

另一个技巧是把命令行解析器单独拿出来做单元测试。我写过一段临时代码，循环读取测试用例字符串，解析后逐项打印argc和每个args内容。像" ls -l "、" "、""、"ls\t-l"这些边界用例，跑一遍就能发现解析器在哪一步处理有问题。字符串解析是Shell一切功能的地基，这个环节稳了，后面少很多事。

最后分享一个我在项目编码时养成的习惯：所有系统调用都要检查返回值。open、pipe、dup2、fork、execvp、getcwd，这些函数的失败都会影响整个Shell的稳定性。虽然代码会因此变啰嗦一点点，但在调试时能省下无数时间，因为我们不需要靠猜来定位问题，而是直接看到哪个系统调用报错，错误码是什么，一步到位。Shell程序算是系统编程的入门项目，把“检查每个系统调用”的习惯练出来，对你后续写服务端代码、写工具链代码都非常有帮助。