如何让TTY程序在stdout管道到less时正常工作？

这个问题我太熟了——之前做终端工具的时候踩过一模一样的坑！你的程序写/dev/tty能躲开文件重定向的坑，但碰到less这种会接管终端的管道程序就乱套，核心原因其实是你的程序和less在同时往同一个终端输出，互相抢地盘。而fzf、fx能正常工作，是因为它们把「终端UI交互」和「数据输出」的边界划得特别清楚。

下面给你几个落地的解决思路：

1. 严格区分「UI内容」和「结果数据」的输出渠道 #

你得把程序的输出拆成两部分：

• 全屏UI、交互提示这类给用户操作看的内容：直接写入控制终端（也就是/dev/tty），这部分只和用户的终端交互，和stdout没关系。
• 最终要传递给管道的数据：专门输出到stdout，这部分才会被less接收。
  比如fzf就是这么干的：先在终端显示筛选UI，等你选完内容，它就退出UI模式，把选中的文本输出到stdout，让less去显示结果。这样两者的输出完全不重叠，自然不会乱。

2. 启动时检测终端状态，动态切换行为 #

在程序刚启动的时候，用isatty()函数检查一下stdout是不是终端：

• 如果stdout是终端（比如你直接在命令行运行程序）：正常显示全屏UI，结果也可以直接输出到终端。
• 如果stdout不是终端（比如管道到less）：先临时显示交互UI，等用户操作完成后，一定要清理终端状态（比如恢复光标位置、清空临时UI内容），再把结果输出到stdout交给less。
  这里划重点：清理终端这步绝对不能省！要是你的程序退出时没把终端恢复成默认模式，less的UI就会和你残留的UI混在一起，变成你看到的“乱套”情况。

3. 别和管道程序抢终端控制权 #

当管道后面的程序（比如less）也要操作终端时，你的程序得注意：

• 交互UI运行的时候，可以暂时把终端设成原始模式（raw mode），但操作一完成，立刻把终端设置回默认状态。
• 整个交互过程中，别往stdout输出任何UI相关的内容，只在交互结束后输出最终的干净数据。这样less拿到的就是纯结果，不会混着UI的控制字符。

4. 参考成熟工具的设计逻辑 #

为啥vim这类编辑器会失败？因为它们从设计上就是把整个终端当编辑区域，默认没有「临时交互+输出结果」的模式，当stdout被管道时，它们还是硬要搞全屏编辑，自然就和less的终端操作冲突了。
而fzf的核心思路值得抄：把「用户交互层」和「数据输出层」彻底分开，交互层只和控制终端打交道，数据层只负责给stdout喂结果，两者完全不干扰。

备注：内容来源于stack exchange，提问作者Juri Pakaste