你能用 pty 做什么？

阅读了各种资源，包括http://www.linusakesson.net/programming/tty/我对伪终端的结构和使用仍然很困惑和好奇 在 Linux 终端（bash 不是 tty）中，我们有三个流：

• stdin
• stdout
• stderr

每个文件都有一个文件描述符。 这些文件描述符映射到流 FILE*。 例如，我们可以使用 fileno() 和 fdopen() 在它们之间进行切换。

我可以用 pty 做什么？

我通常认为 stdout、stdin 和 stderr 与进程相关联。 我认为说有一个与 pty 关联的 stdout、stdin 和 stderr 是不正确的。 因此，给定一个 pty（对于像 bash 这样的进程而不是它的 pid），您如何获取它们并将它们连接到 bash 意义上的终端？

单个文件描述符（对于 pty）如何映射到三个流？ （显然不是） 它能以某种方式映射到一个进程吗？

当使用 openpty() 时，我想连接流程在主终端和从终端上，您需要为 stdin、stdout 和 stderr 设置单独的管道，并使用选择循环连接它们并在它们之间传输数据。

但是您是否可以假设 stdin 和 stdout 已连接（通过 tty）并仅设置一个 stderr 管道以避免 stdout 和 stderr 被合并？

如果我们有一个主进程和从进程，“额外”tty 实际上为我们做什么？

以下是我认为我知道并且相关的一些事情：

The 打开pty()函数返回一对文件描述符，代表伪终端的主端和从端。

每个文件描述符都指向字符设备 - 请参阅https://man7.org/linux/man-pages/man7/pty.7.html

现在 Unix 中的设备只是特殊文件，因此文件描述符是有意义的。

bash 终端有三个流，但 tty 只是一个通道（stdout 和 stderr 之间没有区别）。 虚拟终端（tty）也有一些“魔力”（例如线路规则）。

如果我要问 pty 的 FD 映射到什么文件，它将是设备文件 /dev/ptyX 或其他文件。

由 openpty() 创建的主/从通道的两端都有一个“终端”。

它实际传输什么数据？

我通常将文件描述符视为表示文件的内核结构表的索引。 显然，其中一些文件是流（FILE* 的内核版本），其中一些 很特别。

与终端 (tty) 关联的主要用户空间结构是使用 tcgetattr 从 FD 获得的 termios。 这允许您设置终端参数，但它不会识别任何流或进程 或行纪律。

对于您认为是文件的 FILE* 或 fd，有一组非常清晰且常用的 API 定义了您可以执行的操作。

我模糊地知道我可以用字符设备做什么（例如https://unix.stackexchange.com/questions/37829/how-do-character-device-or-character-special-files-work).

但是你能用 pty 做什么呢？

给定一个流，我们可以使用 isatty() 确定它是否有关联的 tty，并使用 ttyname() 识别该 tty。 所以在内部某个地方有一些东西是知道的 tty 和流是关联的。 isatty(STDERR_FILENO) 也是 true，所以它不仅仅是 stdin 和 stdout。

最初引起我兴趣的是一个程序，它应该是一个守护进程，但却创建了一个 ncurses UI。我一直在考虑如何让进程打开其 ncurses 按需 UI（在 pty 中）。屏幕程序可以让你做到这一点，但它在幕后做了什么。

描述此用例的问题是 -将终端附加到作为守护进程运行的进程（以运行 ncurses UI）

看待这个问题的另一种方式是从面向对象的角度来看。

有哪些函数以“pty”作为参数。它们有什么用？ 如果我有一个 pty 对象。它会有哪些方法呢？

如果仅列出这些函数，则手册页中会缺少一些关键信息。前置条件、后置条件和不变量是什么。

文件描述符是每个进程的标识符，指的是内核内部文件描述。文件描述包括常规文件的位置，以及是否打开该文件以进行读取、写入、两者或仅用于路径操作。这些在文件中称为文件状态标志fcntl() 手册页。每个文件描述符都有自己的描述符标志（当前只有一个，close-on-exec，O_CLOEXEC/FD_CLOEXEC）。

FILE 流是标准 C 库抽象。如果我们忽略 GNU fopencookie() 扩展，则所有 C 流都只与一个文件描述符关联，并且只有一个 C 流可以与给定文件描述符关联。 （当然可以复制文件描述符，并使用 fdopen() 将 FILE 流与新的重复文件描述符关联起来。但是，C 库不知道两个单独的流现在共享底层文件位置，这在描述符引用文件时可能会导致问题。当描述符引用设备（例如终端或伪终端）并且原始描述符以兼容模式（读/写/两者）打开时，就没有问题。）

伪终端基本上是一个双向管道，中间有内核 termios 层。在伪终端中运行的典型进程具有引用相同文件描述的所有三个标准描述符：伪终端的从端。

termios 层不仅仅对从端读写的数据进行少量处理：它还会导致信号上升。每个伪终端还与一个大小（行数和列数，以字符为单位）相关联。当伪终端的主控端改变大小时，前台进程组中的每个进程（下面解释）都会收到一个SIGWINCH信号。如果主机关闭伪终端，则所有将其作为控制终端的进程都将收到 SIGHUP 信号。 （这也是为什么/如何在运行命令或程序时关闭终端窗口通常会杀死该命令或程序。）

每个进程最多可以有一个控制终端。每个终端最多可以与一个前台进程组关联（通过管理tcgetpgrp() 和 tcsetpgrp()）。的概念session (getsid(), setsid()、前台进程组和后台进程组都涉及终端（或伪终端）。

当进程将所有三个标准 C FILE 流连接到终端或伪终端时，标准输入从主站接收数据（通过 termios 层），标准输出和标准错误都将数据发送到主站（通过 termios 层）。所以，标准输入、输出和错误并不直接相互连接，仅连接到同一个终端/伪终端从端。

假设您是一名 GTK+3 C 程序员，并且想要创建自己的终端窗口应用程序，例如 xterm 或 gnome-terminal。

The application would create a pseudoterminal for each window. Whenever it receives keyboard events, it would write the corresponding key sequence (1 for 1, : for :, and so on) to the master pseudoterminal descriptor. Everything it would read from the master pseudoterminal descriptor, it would render in the window. For the slave side, the application forks a child process, opens the slave side for all three standard streams, and either executes the equivalent of /bin/login -f $(id -un) with root privileges, or does the equivalent for the current user itself. Essentially, certain housekeeping is done for the user, and finally a login shell is opened for the user in their home directory.

大多数终端模拟器都支持ANSI 转义码以及 xterm 的扩展。终端信息数据库和 ncurses 应用程序依赖 TERM 环境变量设置为当前终端类型。 （xterm-256color 可能是 Linux 中最常见的，但也支持其他颜色。终端仿真器应在从属端启动进程时设置正确的 TERM 环境变量；本身没有自动检测。）

所有需要伪终端的事情都涉及类似终端的环境。它可能面向人类用户（如上面的 GUI 终端应用程序），也可能面向在终端中工作并代表用户操作的应用程序，如 nano、vim、emacs、links 或 lynx。

The way screen其工作原理是，即使用户未连接到该屏幕进程，它也会维护应用程序正在运行的伪终端。当用户想要分离（即断开连接但让进程继续运行）时，屏幕应用程序（运行进程的伪终端的主端）与人类正在使用的终端/伪终端分离，但继续运行。为了恢复，screen -r命令（以及已经运行 screen 时的键盘快捷键）将用户终端或伪终端重新连接到 screen 应用程序。

本质上，使用这样的终端多路复用器，您拥有连接到多路复用器应用程序的真实用户终端或伪终端（可以是像 xterm 或 gnome-terminal 这样的终端仿真器，甚至是像到本机的远程 SSH 连接这样的非终端进程） ，中继按键和输出当连接时到伪终端（多路复用器应用程序是其主终端），shell 或其他应用程序在该伪终端下运行。