scanf仅在stdin为/dev/pts/*时等待输入的原因及普通文件解决方法

核心逻辑是：文件描述符的读写阻塞行为完全由它绑定的底层文件类型决定，和描述符本身的编号（比如0号标准输入）没有任何关系。

• 绑定/dev/pts/0这类终端设备时：终端属于字符型设备，本身的read操作内置了「无数据则挂起等待」的逻辑。当设备的输入缓冲区没有任何可读内容时，read系统调用会主动将当前进程置为睡眠状态，直到有新输入写入缓冲区才会唤醒进程返回数据。glibc封装的scanf本质上就是对read(0, ...)的二次封装，因此自然表现为阻塞等待输入。
• 绑定inp.txt这类普通磁盘文件时：普通文件的read操作没有内置“等待新写入”的语义，所有读取行为完全基于当前的文件偏移值。只要文件偏移未到达文件末尾，系统会直接把偏移位置对应的磁盘存量内容读出后立刻返回；就算偏移已经到达文件末尾，read也会直接返回0（代表文件结束标记EOF），绝对不会主动等待“后续是否有新数据被写入文件”。glibc的scanf在封装read时，一旦检测到read返回0就会直接终止输入流程，这就是scanf绑定普通文件时不阻塞、直接读走已有内容的根本原因。

常见误区澄清：就算给普通文件加上阻塞模式的打开标记，它的“阻塞”也仅指等待磁盘IO完成把页缓存数据加载到用户态，永远不会出现等新数据写入才返回的行为，这是和终端设备最本质的实现差异。

• 自定义文件偏移的等待逻辑绕开EOF直接返回的特性：在调用scanf之前，先通过lseek获取当前文件偏移位置，通过fstat记录当前文件总大小；如果当前偏移已经和文件总大小相等（也就是到了文件末尾），就用poll循环监听文件状态，直到检测到文件大小超过之前记录的值（也就是有新内容被写入），再继续触发scanf读取。这种方式不需要修改原有的scanf调用逻辑，只需要在读取前补上“等新内容”的等待流程。
• 用管道/命名管道作为中间转发层替代直接绑定普通文件：创建一个双向匿名管道或者FIFO命名管道，把0号标准输入指向管道的读端。管道的read语义和终端设备完全一致：没有数据可读时会主动阻塞，直到写端写入新内容才会返回。后续只需要把普通文件的内容实时转发到管道的写端，就能完全复现终端输入的阻塞等待效果。
• 借助伪终端（PTY）机制完全复用终端的原生阻塞逻辑：不要直接把普通文件绑定到0号描述符，而是创建一对PTY主从设备，把0号标准输入指向PTY的从端。之后编写逻辑把普通文件的内容按需喂给PTY的主端，此时从端的read操作会完全沿用终端本身的阻塞语义，不需要额外自己实现等待逻辑。

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