为何从stdin调用read()在终端遇换行终止，文件却不会？

问题背景 #

执行以下代码：

ssize_t len = read(0, buf, BUF_SIZE);
perror("read()");
printf ("%i '%s'\n", (int) len, buf);

出现两种不同的读取行为：

• 从终端读取时，read()会在换行符（按下回车）处终止输入且无错误，实现逐行输入；
• 通过Shell重定向从文件读取时，会忽略换行符，持续读取直到填满缓冲区或到达EOF。

针对上述差异，有三个疑问：

1. 为何终端输入会在换行处终止？
2. 这是否意味着终端输入默认是非阻塞的？
3. 如何正确判断是到达EOF（Ctrl-D）还是其他条件导致返回不完整输入？

解答 #

1. 终端输入在换行处终止的原因 #

终端默认工作在规范模式（canonical mode），这是终端的标准交互配置。在该模式下，终端会对输入做行缓冲处理：它会暂存用户输入的所有字符，直到用户按下换行键（或触发EOF），才会把整行数据提交给内核，此时read()才能读取到完整的一行内容。这种设计是为了适配交互式操作场景，允许用户在输入过程中用退格、删除等按键修正输入内容，直到回车确认后才提交数据。

而普通文件不存在行缓冲逻辑，read()会遵循系统调用的默认行为，尽可能读取最多的字节（直到缓冲区填满或文件到达末尾）。

2. 终端输入默认不是非阻塞的 #

终端默认处于阻塞模式。规范模式下的read()会一直阻塞，直到用户输入一行并按下回车（或触发EOF）才会返回。所谓"在换行处终止"只是行缓冲的表现，和非阻塞完全不同——非阻塞模式下read()会立即返回，不管是否有输入数据；而终端默认状态下，若没有任何输入，read()会一直等待，不会返回。

你可以自行验证：运行代码后不输入任何字符，程序会卡在read()调用处，这就是阻塞的典型表现。

3. 区分EOF与不完整输入的方法 #

通过read()的返回值及errno状态可以准确区分：

• 返回值为0：明确表示到达EOF。对于终端来说，若用户刚按下回车就按Ctrl-D，read()会直接返回0；若当前行有未提交的输入，第一次按Ctrl-D会提交当前行（read()返回该行长度），第二次按Ctrl-D才会触发EOF，返回0。
• 返回值大于0但小于BUF_SIZE：
  • 终端场景：这通常是因为用户输入的一行数据长度小于缓冲区大小，按下回车后read()返回该行的字节数（包含换行符）。
  • 文件场景：可能是文件剩余数据不足BUF_SIZE，或是调用被信号中断。此时可检查errno：若errno未被设置，说明是正常读取到文件末尾；若errno为EINTR，则是被信号中断导致的不完整读取。

注意：read()不会自动在缓冲区末尾添加'\0'，直接用printf("%s")输出可能会出现乱码，建议读取完成后手动添加终止符，比如if (len > 0 && len < BUF_SIZE) buf[len] = '\0';

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