进程间通信：Pipe vs PTY

最近一时兴起，想自己动手写一个终端模拟器。发现直接使用 Rust 标准库的 std::process::Command 启动子进程时，很多预期的终端行为都失效了：光标控制指令被忽略，按键没有回显，甚至 vim 这种程序都无法正常进入交互界面。问题的根源在于子进程的标准输入输出背后接的是管道（Pipe），而不是伪终端（PTY）。

Pipe 与 PTY 的区别

在 Linux 进程模型中，虽然我们可以通过多种方式启动子进程并重定向其 I/O，但内核对不同“通道”的处理逻辑截然不同。

• Pipe（管道）：一种半双工的字节流通道。内核只负责将数据从一端搬运到另一端，它并不关心数据的内容是什么。在管道模式下，子进程会将自己视为处于“非交互环境”，为了效率通常会开启块缓冲，并关闭颜色输出。
• PTY（伪终端）：它模拟了真实的物理终端行为。数据在传输过程中会经过内核的终端子系统，受到“行规程”（Line Discipline）的处理。这意味着像 Ctrl+C、退格键、回车符等都会被赋予特殊的处理逻辑，而不是作为纯粹的字节。

终端模拟器必须使用 PTY 来与 Shell 通信，否则子进程会因为探测到自己没运行在终端（TTY）上而拒绝提供交互功能。

特性	Pipe 模式	PTY 模式
内核处理	简单的字节搬运	终端语义处理（行规程）
交互性	低（通常用于非交互式自动化）	高（支持实时交互、反馈）
典型行为	块缓冲、无颜色、忽略信号字符	行缓冲、开启颜色、处理信号字符
适用场景	日志重定向、过滤工具 (grep)	终端模拟器、SSH 远程登录

TTY、PTY 与 PTS

• TTY (Teletypewriter)：这是一个最宽泛的总称。无论是物理上的打字机、串口线，还是软件模拟出来的终端，在 Unix 体系下都被抽象为 TTY 设备。
• PTY (Pseudo Terminal)：专门指代那种成对出现的“伪终端”机制。它包含一个 Master 端（由终端模拟器持有）和一个 Slave 端（由子进程如 Bash 持有）。
• PTS (Pseudo Terminal Slave)：这是 PTY 机制在现代 Linux 下的具体实例路径。当你打开一个新终端窗口，内核通常会在 /dev/pts/ 目录下分配一个编号，如 /dev/pts/0。

此外，还有一些特殊的设备路径需要注意：

• /dev/ptmx：它是 PTY 的控制中心（Multiplexer），通过打开这个文件，开发者可以向内核申请一对新的 Master/Slave。
• /dev/tty：这是一个极其特殊的符号链接，它总是指向当前进程的“控制终端”。如果你想确认自己的程序当前正运行在哪个终端上，可以直接读取这个路径。
• 串口设备：例如 /dev/ttyS0 或 /dev/ttyUSB0。它们在内核中同样属于 TTY 子系统，但对应的是真实的物理硬件端口。

当你决定使用 PTY 来实现终端模拟器后，还有一些绕不开的工程细节需要处理。

由于 PTY 模拟的是物理设备，它有自己的“边界”（行数和列数）。如果你的终端窗口调整了大小，必须通过 ioctl 系统调用通知内核，内核会产生一个 SIGWINCH 信号发送给子进程。如果缺少这一步，你会发现 vim 或 top 的界面在窗口拉伸后会出现严重的排版错乱。

默认情况下，PTY 通常处于 Canonical 模式（加工模式），内核会帮你处理退格键回显。但大多数现代终端程序（以及你正在写的模拟器）更倾向于使用 Raw 模式（原始模式）。在 Raw 模式下，所有的按键直接传给应用程序，模拟器需要自己负责渲染字符的回显和删除逻辑，这给了前端更大的控制权。

跨平台差异

在 Linux 下我们使用 forkpty 或 /dev/ptmx 进行操作，而 Windows 平台则有自己的 ConPTY 机制。如果你希望编写一个跨平台的工具，推荐使用类似 portable-pty 这样的库，它们通过抽象层屏蔽了底层的各种繁琐细节，让你能更专注于终端逻辑本身。