Is this kind of behavior defined by standard?

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

The above read 5 characters from stdin,but if I input more than 5:

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

The remaining charact开发者_如何学JAVAers will be executed as shell commands.

Is this kind of behavior defined by standard?

---

Sort of :-)

Your program reads 5 characters, and that's it. Not less, not more. The rest remain in the terminal buffer and get sent to your shell once your C program terminates.

Since you are using read(), which is a raw system call, instead of any of the C stdio buffering alternatives this behaviour is not just expected, but required.

From the POSIX standard on read():

The read() function shall attempt to read nbyte bytes from the file associated with the open file descriptor, fildes, into the buffer pointed to by buf.

...

Upon successful completion, where nbyte is greater than 0, read() shall mark for update the st_atime field of the file, and shall return the number of bytes read. This number shall never be greater than nbyte.

...

Upon successful completion, read() [XSI] [Option Start] and pread() [Option End] shall return a non-negative integer indicating the number of bytes actually read.

I.e. read() should never read more bytes from the file descriptor than requested.

From the related part on terminals:

It is not, however, necessary to read a whole line at once; any number of bytes, even one, may be requested in a read() without losing information.

...

The last process to close a terminal device file shall cause any output to be sent to the device and any input to be discarded.

Note: normally your shell will still have an open file descriptor for the terminal, until you end the session.

---

That has nothing to do with any standard, it's up to your runtime what to write to stdin. Your runtime makes the standard input available to your program, which reads some bytes from it and quits, and then the remaining bytes are processed by the runtime itself -- if you can configure it to clear all the file descriptors after forking a process, you could maybe prevent this behaviour, but that would seriously impede most of the standard command line workflows which rely on attaching one process's input to another process's output...