这是一个非常好的问题，它触及了 Linux/Unix 系统设计中的一个核心概念。简单回答是：为了实现灵活性和复用性，将终端硬件管理与会话逻辑分离开来。
下面我们来详细拆解这个问题。
为什么不能直接从键盘和显示器读取？
在计算机的远古时代（大型机、小型机时代），用户是通过一个物理终端（比如电传打字机或后来的 CRT 终端）连接到主机的。这个终端就是一套实实在在的硬件，包括键盘和显示器。
对于运行在主机上的 Shell 来说，它只需要一个简单的“对话”接口：
- 标准输入：从某个地方读取用户的命令。
- 标准输出：将结果输出到某个地方。
- 标准错误：将错误信息输出到某个地方。
如果 Shell 被设计成直接与物理键盘和显示器驱动打交道，会带来几个严重问题：
- 缺乏灵活性：Shell 程序将与特定的硬件绑定。换一种终端设备，可能就需要修改 Shell 的代码。
- 无法实现远程登录：这是最关键的一点。当网络出现后，用户希望通过
telnet或ssh从远程登录。这时，用户的键盘和显示器在本地，而 Shell 进程运行在远端的服务器上。它们之间隔着网络，而不是直接的硬件连接。 - 无法实现图形终端模拟：像 GNOME Terminal、Konsole、iTerm2 这样的图形界面终端程序将无法工作。这些程序在图形界面里用一个窗口来模拟物理终端的行为。
伪终端的解决方案：一个“演员”代替“实物”
为了解决上述问题，Unix/Linux 引入了 伪终端 的概念。你可以把它想象成一对双向的、虚拟的管道，或者一个双向的 FIFO 队列。这对管道由两部分组成：
- 主设备：
/dev/ptmx - 从设备：
/dev/pts/#（例如/dev/pts/0,/dev/pts/1...）
工作流程如下：
- 当你打开一个终端模拟器（如 GNOME Terminal）或通过 SSH 登录时，终端模拟器或 SSH 守护进程会首先打开主设备。
- 操作系统会自动创建一个对应的从设备，比如
/dev/pts/1。 - 终端模拟器会
fork()一个新的进程，并让这个新进程去打开那个从设备，并将其作为自己的标准输入、标准输出和标准错误。 - 这个新进程通常就是你运行的 Shell（如 bash、zsh）。
现在，数据流是这样的：
- 你的键盘输入 -> 终端模拟器 -> 主设备 -> 从设备 -> Shell 的标准输入
- Shell 的标准输出 -> 从设备 -> 主设备 -> 终端模拟器 -> 你的显示器
伪终端带来的巨大好处
-
对 Shell 透明：
Shell 程序本身完全不知道另一端连接的是物理终端、网络连接还是一个图形窗口。它只是像往常一样，从自己的标准输入读取数据，向标准输出写入数据。它认为自己是在和一个真正的终端对话，但实际上它是在和伪终端的“从设备”对话。这实现了完美的抽象。 -
实现远程登录：
在 SSH 的场景中，本地的 SSH 客户端和远程的 SSH 守护进程建立了网络连接。远程的 SSH 守护进程就扮演了“终端模拟器”的角色。它创建一个伪终端，并启动用户的 Shell 连接到其从设备。这样，本地的键盘输入通过网络传到远程的 SSH 守护进程，再通过主设备写入从设备，最后被 Shell 读取。输出则反向流动。 -
实现图形终端模拟器：
GNOME Terminal 等程序也是同样的原理。它作为一个图形应用程序，创建了一个伪终端，然后启动 Shell。它将从主设备读取到的数据渲染到图形窗口上，并将窗口接收到的键盘事件写入主设备。 -
支持行编辑、作业控制等高级功能：
伪终端不仅仅是一个管道。它模拟了真实终端的很多行为，比如行缓冲（在按下回车键前可以编辑）、信号（如Ctrl+C发送SIGINT，Ctrl+Z发送SIGTSTP）。终端模拟器（主设备端）负责解释这些特殊的控制字符和按键，并将其转换为相应的信号或操作，通过伪终端发送给 Shell。
总结
| 特性 | 没有伪终端（直接读写硬件） | 有伪终端 |
|---|---|---|
| 硬件依赖 | 强，与特定终端绑定 | 无，统一的抽象接口 |
| 远程登录 | 无法实现 | 核心基础 |
| 图形终端 | 无法实现 | 核心基础 |
| 设计哲学 | 紧耦合，不灵活 | 松耦合，符合 Unix“一切皆文件” |
所以，提出伪终端这个概念，是 Unix/Linux 设计哲学中 “通过抽象和组合来解决复杂问题” 的完美体现。它将终端的会话管理逻辑（由 Shell 负责）和终端硬件管理逻辑（由终端驱动/终端模拟器负责）清晰地分离开，使得两者可以独立发展和复用，从而极大地增强了系统的灵活性和功能。