这种行为是由标准定义的吗?

时间:2011-07-01 14:46:43

标签: c

#include <unistd.h>
int main(int argc, char* argv[])
{
  char buf[500];
  read(0, buf, 5);
  return 0;
}

上述read来自stdin的5个字符,但如果输入的内容超过5

12345morethan5
[root@ test]# morethan5
-bash: morethan5: command not found

其余字符将作为shell命令执行。

这种行为是否由标准定义?

2 个答案:

答案 0 :(得分:5)

排序: - )

你的程序读取5个字符,就是这样。不少,不多。其余的保留在终端缓冲区中,并在C程序终止后发送到shell。

由于您使用的是read(),这是一个原始系统调用,而不是任何C stdio缓冲备选方案,这种行为不仅仅是预期的,而是必需的

来自read()上的POSIX标准:

  

read()函数应尝试   从文件中读取nbyte个字节   与打开的文件相关联   描述符,fildes,进入缓冲区   buf指出。

     

...

     

成功完成后,在哪里   nbyte大于0,read()必须   标记用于更新st_atime字段   该文件,并将返回该号码   读取的字节数。 此号码永远不会   大于nbyte。

     

...

     

成功完成后,阅读()   [XSI] [选项开始]和pread()   [Option End]将返回a   非负整数表示   字节数实际上读取。

即。 read() 永远不会从文件描述符中读取比请求更多的字节。

来自终端上的related part

  

但是,没有必要阅读   一下子整整一行;任何数量的   字节,甚至一个,可以在a中请求   读取()而不会丢失信息。

     

...

     

关闭终端设备文件的最后过程将导致任何输出发送到设备并丢弃任何输入。

注意:通常你的shell仍会有终端的打开文件描述符,直到你结束会话。

答案 1 :(得分:0)

这与任何标准无关,由运行时决定写入stdin的内容。您的运行时使标准输入可用于您的程序,该程序从中读取一些字节并退出,然后剩余的字节由运行时本身处理 - 如果您可以将其配置为在分配进程后清除所有文件描述符,则可能会阻止这种行为,但这会严重阻碍大多数依赖于将一个进程的输入附加到另一个进程输出的标准命令行工作流......