基于TCP搭建远程shell时客户端不显示shell提示符问题求解

问题判断结论 #

你对stderr重定向的判断是正确的，你写的这段dup2循环代码确实将stdin(0)、stdout(1)、stderr(2)都成功重定向到了客户端连接fd，无效命令可以正常返回错误信息也验证了stderr的重定向逻辑没有问题。

问题根因 #

你观察到的isatty(client->fd)返回0就是问题的核心原因：
bash默认有运行模式检测逻辑，只有运行在交互式模式，且标准输入输出绑定tty设备时，才会输出PS1、PS2提示符。你当前用TCP socket作为输入输出载体，不属于tty设备，所以bash自动切换到了非交互式模式，主动关闭了提示符输出，这个是bash的原生设计，和readline无关。

修复方案 #

轻量修复（仅展示提示符）

启动bash时添加-i参数强制开启交互式模式，修改你的execve调用参数即可：

execve("/bin/bash", (char *[]){"bash", "-i", NULL}, NULL);

修改后即使运行在非tty的socket上，bash也会正常输出提示符。

完整终端体验修复

如果需要支持ctrl+C中断命令、上下键翻历史命令、方向键移动光标等本地终端的全部功能，你需要在服务端用伪终端（PTY）承载bash进程：

1. 服务端调用posix_openpt()打开伪终端主设备，依次调用grantpt()、unlockpt()完成伪终端的权限配置
2. 用ptsname()获取伪终端从设备的路径，打开从设备文件
3. fork子进程运行bash时，将子进程的0/1/2文件描述符全部dup2到伪终端从设备
4. 父进程负责双向转发数据：将伪终端主设备收到的bash输出转发到客户端socket，同时将客户端socket发送的用户输入转发到伪终端主设备
   这种方案下bash检测到输入输出是tty设备，会完全遵循本地终端的交互逻辑，体验和本地使用shell完全一致。

客户端优化提示 #

你当前用nc作为客户端的话，如果使用PTY方案，可以搭配rlwrap工具获得命令编辑能力，执行rlwrap nc localhost 8080连接即可。

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