向远程bash shell传递控制字符的方法（SSH替代方案）

你用管道启动bash的方案从底层逻辑上就不可能支持交互式操作：当bash检测到自己的标准输入输出连接的是管道而非真实终端设备时，会自动切换到非交互模式，默认关闭行编辑、Tab补全、作业控制、快捷键信号响应（Ctrl+C/Ctrl+Z等）所有交互特性，就算你手动把控制字符写入管道，bash也不会按交互逻辑处理这些输入。

所有交互式终端场景——包括本地控制台、SSH远程会话、tmux/screen终端复用、甚至GUI终端模拟器——底层都是靠伪终端实现的，没有替代方案。
伪终端是操作系统提供的一对双向通信的设备节点，分为两端：

• 从端（slave）：对运行在其上的程序来说，和真实的物理终端没有任何区别。你把bash的标准输入、输出、错误流全部绑定到从端，启动时加-i参数强制进入交互模式，bash就会自动开启所有和本地操作一致的行为：Tab补全、快捷键响应、颜色输出、作业控制、提示符渲染，不需要你额外做任何适配。
• 主端（master）：由你的代理进程持有，是透传数据的唯一入口。

透传逻辑 #

你不需要做任何协议解析、命令和响应的匹配，只需要做纯粹的双向字节流转发即可：

• 客户端发来的所有字节，不管是普通的命令字符，还是Tab对应的\t、Ctrl+C对应的\x03、Ctrl+D对应的\x04这类控制字符，原样写入主端即可，效果和你在本地终端敲下这些按键完全一致。
• 从主端读到的所有字节，不管是命令正常输出、补全候选列表、还是控制光标移动、清屏、渲染颜色的终端控制序列，原样转发给客户端即可，客户端拿到字节流直接喂给本地终端渲染，就能得到和本地操作完全一致的体验。

• 启动bash时不要做多余的重定向，伪终端从端本身是双向设备，stdout和stderr默认都会输出到从端，不需要手动做2>&1重定向。
• 拿到主端文件描述符后，一定要将其配置为raw原始模式，关闭内核默认开启的行缓冲、输入回显、特殊字符拦截逻辑，否则会出现输入重复、控制字符不生效、需要敲回车才会提交输入的问题。
• 不要在代理层做任何字节过滤、缓冲：所有输入必须收到就立刻写入主端，所有输出必须读到就立刻转发给客户端，不要等凑够一行、等命令执行完成再发——交互式场景下单字节的控制字符（比如Tab、Ctrl+C）就需要触发逻辑，缓冲会直接导致交互失效。
• 不需要维护命令和输出的映射关系：本来交互式shell就不存在请求-响应一一对应的逻辑，后台进程异步输出、提示符刷新这些逻辑bash会自己通过终端控制序列处理，你做透明字节流转发就不会有逻辑问题。

不同编程语言都有成熟的PTY封装，不需要从零实现系统调用逻辑，核心逻辑可以参考最简化的C实现：

#define _GNU_SOURCE
#include <pty.h>
#include <unistd.h>
#include <sys/wait.h>

int main() {
    int master_fd;
    // 创建PTY对，fork子进程，自动将子进程的stdio绑定到从端
    pid_t child_pid = forkpty(&master_fd, NULL, NULL, NULL);
    if (child_pid == 0) {
        // 子进程内启动交互式bash
        execlp("bash", "bash", "-i", NULL);
        _exit(1);
    }
    // 父进程逻辑：
    // 1. 从客户端收到的所有字节 -> write(master_fd, buf, len)
    // 2. 从master_fd读到的所有字节 -> 发送给客户端
    waitpid(child_pid, NULL, 0);
    return 0;
}

Python标准库pty模块、Node.js生态的node-pty、Go标准库搭配PTY扩展包都可以快速实现同样的逻辑，底层原理完全一致。

内容的提问来源于stack exchange，提问作者Zohar81