从事系统编程的开发者几乎每天都会与 Shell 交互，但真正理解其内部工作机制的人却不多。Shell 既是交互式程序，也是一门小型的命令行语言：它需要解析用户输入、展开环境变量、管理外部进程、处理管道连接，并在终端中提供历史记录与命令补全等交互功能。从零实现一个玩具 Shell，恰好是 UNIX 进程模型、文件描述符操作与信号处理等核心概念的工程实践。
REPL 交互骨架
Shell 本质上是一个读取 - 求值 - 打印循环（Read-Eval-Print Loop），首先需要构建交互式骨架。与普通程序不同，Shell 需要在终端中持续运行并维护状态，包括上一次命令的退出状态、是否处于交互模式等。实现时需要安装信号处理器，以优雅地处理用户中断（Ctrl+C）和退出（Ctrl+D）。
typedef struct {
int last_status;
int running;
int interactive;
} Shell;
核心循环的逻辑并不复杂：读取一行输入，对该行求值，然后继续等待下一行输入。关键在于 read_line 函数需要返回三种情况 —— 成功读取到一行、遇到文件结束符（EOF）、或发生真实错误。eval_line 函数则负责解析并执行用户输入的指令。
从文本到 argv：分词与结构化
在执行命令之前，Shell 必须将用户输入的原始文本拆分成词元（token），并将这些词元组织成可执行的命令结构。这一步骤是 Shell 语言实现的基础，但考虑到玩具项目的目标，分词逻辑可以保持简洁 —— 只需按空格和制表符分割，同时将管道符 | 作为语法元素单独处理。
分词发生在环境变量展开之前，这样 $HOME 这样的词元可以在执行前被替换为实际值。需要注意的是，管道符本身不应被展开，因为它属于语法而非数据。
外部命令的执行与进程创建
Shell 本身不能被替换为要运行的命令，否则 Shell 进程将不复存在。因此，Shell 必须通过 fork 创建子进程，在子进程中用 execvp 加载并运行目标程序，而父进程则使用 waitpid 等待子进程结束。
pid = fork();
if (pid == 0) {
execvp(argv[0], argv);
_exit(errno == ENOENT ? 127 : 126);
}
这里有一个容易忽略的细节：子进程必须调用 _exit 而非 exit。这是因为 exit 会执行 libc 的清理函数，而在已经 fork 的子进程中，这些清理函数可能导致重复执行（如输出缓冲区被刷新两次），从而产生意料之外的副作用。另一个关键点是等待子进程时需要处理 EINTR 中断 —— 当终端发送中断信号时，waitpid 可能被信号打断，此时应当重试等待，而非直接放弃，否则 Shell 将失去对子进程状态的追踪。
内建命令：为什么 cd 不能 fork
在众多命令中，cd 是一个特殊的存在。如果 Shell fork 出一个子进程，然后子进程调用 chdir 改变目录，那么只有子进程的目录会发生变化；当子进程退出后，父进程仍然停留在原来的目录。这意味着 cd 必须作为内建命令（builtin）在 Shell 自身进程中执行，而非通过 fork 创建子进程。
实现时需要检查命令是否为内建命令，如果是则直接在当前进程中执行相应的处理函数。
if (strcmp(command->argv[0], "cd") == 0) {
return run_builtin_cd(shell, command);
}
当用户只输入 cd 而不带参数时，Shell 应默认将目录切换到 HOME 环境变量指定的路径，这是 UNIX Shell 的传统行为。
环境变量展开
在执行命令之前，Shell 会对输入进行 Rewrite。除了前一步提到的分词，还需要处理环境变量展开。当用户输入 echo $HOME 时，Shell 应将其转换为实际的家庭目录路径再执行。实现时需要识别 $ 开头的词元，并在环境变量表中查找对应的值。
除了普通的环境变量，还有一个特殊的内置变量 $?，它表示上一条命令的退出状态。在交互式 Shell 中，显示这个状态值能够让用户快速判断上一步操作是否成功，这小小细节能显著提升玩具 Shell 的真实感。
管道实现：连接进程的标准输入输出
管道是 Shell 最强大的特性之一。在 UNIX 中，管道本质上是内核提供的一块缓冲区，一端连接写进程的标准输出，另一端连接读进程的标准输入。对于 cmd1 | cmd2 这样的命令，Shell 需要在两个进程之间建立一条通道；而对于 cmd1 | cmd2 | cmd3 这样的多命令管道，则需要创建 N-1 条管道。
核心系统调用是 pipe()，它创建一对文件描述符：pipefd[0] 是读端，pipefd[1] 是写端。数据写入写端后会被内核缓冲，直到从读端读取。Shell 为管道中的每个命令创建一个子进程，并在子进程中使用 dup2 将标准输入重定向到上一条管道的读端，将标准输出重定向到下一条管道的写端。这样，原本从标准输入读取的程序会自动从管道中获取数据，而写入标准输出的程序会自动将数据送入管道，无需任何修改。
if (prev_read != -1) {
dup2(prev_read, STDIN_FILENO);
}
if (pipefd[1] != -1) {
dup2(pipefd[1], STDOUT_FILENO);
}
这种设计体现了 UNIX 哲学的核心原则：每个程序只需做好一件事，通过标准输入输出进行组合。管道的同步机制也是自动的 —— 如果 grep 读取的速度比 ls 写入的速度快，它会阻塞等待；当 ls 写入过快而 grep 尚未读取时，管道缓冲区满，ls 也会阻塞。这种内置的流控使得 Shell 无需额外的同步逻辑，只需等待所有子进程完成即可。
交互体验：readline 库的力量
到目前为止，Shell 已经能够正确执行命令、处理管道和变量展开，但用户界面仍然相当原始。直接在终端中按下左箭头或右箭头并不会神奇地移动光标 —— 终端只会发送转义序列，如 ^[[D。要实现真正的行编辑、历史导航和命令补全，最直接的方式是引入 GNU readline 库。
引入 readline 后，Shell 自动获得了行编辑能力和历史记录功能。每次用户按下回车，输入的行会被自动保存到历史记录中，通过上下箭头可以回溯之前执行的命令。更进一步，还可以实现 Tab 补全功能 —— 当用户输入部分命令并按下 Tab 时，Shell 扫描当前目录和 $PATH 中的可执行文件，返回匹配的建议选项。
这让我们意识到 Shell 背后的复杂性：为了在每次提示符下提供补全建议，Shell 可能需要进行数百次系统调用来探测文件系统。
实践要点与工程权衡
实现这个玩具 Shell 的过程揭示了几个关键的工程实践。进程管理方面，必须正确处理 fork 与 exec 的配合、子进程的退出方式，以及 waitpid 的中断恢复。文件描述符管理需要在父子进程间合理分配和关闭不需要的端点，特别是管道各端的生命周期。分词与展开的顺序很关键 —— 虽然玩具实现跳过了引号处理和完整的解析器，但将语法元素（如 |）与数据区分开是必要的前提。内建命令的设计体现了 UNIX 的核心原则：需要改变 Shell 自身状态的命令必须直接在主进程中执行。最后，交互体验的完善可以借助成熟库（如 readline）快速达成，而不必从头编写终端处理逻辑。
一个可用的玩具 Shell 大约能覆盖日常 Shell 使用的五成场景：启动程序、运行基础 git 命令、以及用管道配合 grep 进行过滤。但仍有大量功能缺失 —— 引号处理、重定向操作符、后台任务支持，以及对复合命令的处理都不在当前实现范围内。
资料来源：本文核心实现思路参考 Andrew Healey 在 healeycodes.com 上发表的《Building a Shell》一文，该项目开源代码见 GitHub/healeycodes/andsh。