从 Unix Mini Shell 到 Browser Playground：我把 fork/exec/pipe 做成了一个可交互 Web 产品

很多操作系统课程里的 Mini Shell 项目，最后都停留在：

但我一直觉得，这种经典 Unix 系统项目其实非常有价值，只是 展示方式太“作业化”了。

面试官很难在短时间内感受到你真正掌握了什么：

• 进程创建
• 父子进程同步
• 文件描述符控制
• 管道 IPC
• stderr 错误链路

所以这次我做了一次彻底升级：

最终效果是：

• 浏览器终端风格 UI
• 实时执行真实 shell 命令
• 支持重定向、单管道、错误输出
• Next.js 前端交互 + API Route
• 后端直接 spawn 自定义 C++ shell
• README / 面试展示可视化拉满

一句话概括这个项目：

一、项目升级思路：为什么我要把 Shell 做成 Web Playground？

传统 Mini Shell 的问题不是技术难度不够，而是：

终端里跑这些：

ls
pwd
echo hello
echo hello | wc -c

你自己当然知道背后发生了什么。

但别人看不到。

尤其在 GitHub 和面试场景里，别人更需要快速理解：

所以我做了一个核心升级：

浏览器里直接输入命令，底层调用自定义 mini_shell 可执行文件，把输出实时渲染回终端 UI。

这样：

二、最终产品效果展示

这是整个产品首页，也是 README 封面图。

我希望它第一眼给人的感觉不是：

而是：

顶部 Hero 区直接定义项目价值：

这是整个项目最核心的设计理念。

这一张是系统 ready state。

Shell 初始化完成，浏览器 terminal 进入可交互状态。

这个阶段对应的是：

• 前端 terminal UI ready
• API route ready
• C++ shell executable ready
• 输入等待状态

基础命令执行演示：

ls
pwd
echo hello

这一部分主要展示：

• parser
• 普通命令执行链路
• stdout 渲染
• terminal history
• auto-scroll session

这一张是我认为项目最有系统味的一张。

集中展示了：

echo hello > out.txt
cat < out.txt
echo hello | wc -c
not_a_command

背后分别对应：

• 文件重定向
• dup2() 文件描述符切换
• pipe() 进程间通信
• stderr 错误路径渲染
• execvp() 失败处理

尤其错误输出这一块，我专门保留了真实错误链路：

exec failed: No such file or directory

这是工程感非常强的一部分。

三、核心架构设计

架构设计我没有做花架子，而是完全对齐代码模块。

整体执行链路：

Browser UI
   ↓
Next.js API Route
   ↓
spawn mini_shell
   ↓
Parser / Dispatcher
   ↓
Executor / Redirection / Pipe
   ↓
stdout / stderr

核心思想是一个 命令分发器（dispatcher）：

• 普通命令 → fork + execvp
• 重定向 → open + dup2 + execvp
• 管道 → pipe + fork × 2

这个分层让整个代码结构非常清晰，也方便后续继续扩展：

• 多级 pipe
• 后台任务
• 长连接 shell session

️ 四、底层核心能力拆解

这个项目核心锻炼的是 Unix 系统编程能力。

1）进程创建：fork()

每条普通外部命令都会创建子进程：

pid_t pid = fork();

父进程负责等待：

waitpid(pid, nullptr, 0);

这部分核心体现：

2）命令执行：execvp()

真正替换子进程镜像：

execvp(args[0], args.data());

这一步是 Shell 最核心的执行能力。

3）文件描述符控制：dup2()

重定向最核心的地方：

dup2(fd, STDOUT_FILENO);

把标准输出切到文件。

这部分是理解 Unix I/O 模型最关键的知识点之一。

4）进程间通信：pipe()

单管道：

echo hello | wc -c

底层本质：

这是典型 IPC 场景。

五、为什么我要做前端产品化

这一步其实是整个项目最值钱的地方。

如果只停留在终端：

但一旦加上 Web Playground，它立刻变成：

这意味着你展示的不再只是：

而是：

这对这些方向非常有说服力：

• 后端工程
• 平台工程
• AI infra
• 远程全栈
• 小团队产品研发

六、这个项目真正拉开的差距

我认为这个项目真正拉开的不是 shell 本身。

而是：

很多人都做过 Mini Shell。

但很少有人会继续往下走到：

这一步决定了：

七、下一步迭代方向

这个项目后续我还会继续升级几个方向：

Shell 内核

• 多级管道 cmd1 | cmd2 | cmd3
• 后台任务 &
• command history persistence
• 混合 pipe + redirection

产品层

• WebSocket 长连接 shell
• session 隔离
• containerized shell runtime
• 用户级多 session playground

目标是继续把它往：

推进。

八、适合哪些岗位

我认为这个项目非常适合下面这些岗位展示：

• 系统开发 / 操作系统相关
• 后端工程
• AI infra / 平台工程
• 分布式系统基础岗位
• 小团队全栈研发
• Remote engineering

因为它同时证明了三件事：

结语

这个项目让我最大的收获不是“又做了一个 shell”。

而是我第一次真正感受到：

当 fork / exec / pipe / dup2 这些抽象概念，第一次在浏览器里变成一个可交互 terminal 时，整个项目的价值被彻底放大了。

这也是我最近非常喜欢的一种工程思路：