为何将VMIN设为0会破坏stdin的DSR ANSI转义序列响应？

核心原理：VMIN的作用 #

VMIN是termios终端配置里的最小读取字符数，和VTIME（超时时间）共同控制read()的行为：

• VMIN=1：read()会一直阻塞，直到至少读到1个字符才返回，没有输入就持续挂起等待。
• VMIN=0：read()会立即返回，有多少字符读多少，没有则直接返回0，属于非阻塞读取模式（配合VTIME=0时）。

最小示例中VMIN=0的异常原因 #

当你发送\033[6n请求终端尺寸时，终端会返回形如ESC[rows;colsR的响应序列。但VMIN=0时，程序的read()会立即执行，此时终端可能还没把完整响应写入输入缓冲区，导致程序只能读到后半部分内容，剩下的响应留在终端缓冲区里。当程序结束后，终端恢复默认规范模式，缓冲区里的残留内容会被直接输出到屏幕，这就是你看到“前半部分仅在程序结束后才输出”的原因。

实际代码中VMIN=1导致冻结的原因 #

最小示例能正常运行是因为环境简单，终端能及时返回响应，但实际代码中冻结通常源于以下问题：

1. 未刷新输出缓冲区：标准输出默认是行缓冲模式，\033[6n不是以换行结尾，导致命令一直留在用户空间缓冲区，根本没发送到终端。终端没收到请求，自然不会返回响应，read()就会一直阻塞等待输入。
2. 未设置VTIME超时：只设VMIN=1但VTIME=0的话，read()会无限阻塞，直到有输入。如果终端因状态异常等原因没返回响应，程序就会彻底冻结。
3. 终端状态被错误修改：实际代码中可能有其他操作修改了终端的规范模式、回显设置等，导致终端的响应无法正常传递到程序的stdin，或者被终端本身拦截。

关键解决注意点 #

要正确实现终端尺寸获取，需要做到：

• 发送\033[6n后立即调用fflush(stdout)，确保命令被发送到终端。
• 设置termios时，配合VTIME设置合理超时，比如VMIN=1且VTIME=5（0.5秒超时），避免无限阻塞。
• 操作完成后必须恢复终端的原始termios设置，避免影响后续终端交互。

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