|I know file descriptor. In my code, stdout redirect to the file(eup.txt).|
doesn't write to the screen. It writes to file descriptor 1. It's just that stdout is arranged to go to the terminal to begin with.
When a program starts, it inherits 3 streams, represented by file descriptors; stdin(0), stdout(1), stderr(2). You are free to close these if you don't want them, and if you do, then start opening files or make socket connections, these file descriptors will be reused.
A file descriptor is just an index into an array of file-like stuff in the kernel.
writes to stdout by writing to file descriptor 1. If you change file descriptor 1 to represent a file, the output will go to a file, or if your change it to represent a tcp client connection, the output will down the network.
Having said that, I suggest you re-read the extract of that man page. Feel free to come back if you don't understand, or have further questions.
Regarding the stuff you've most recently asked:
1. Who flushed the file buffer?
I'm not sure which buffer you mean. It doesn't really have any baring on the issue.
2. In this cae, the file buffer is not fflushed ...
on a file descriptor flushes any data. If you forget to call close and the program terminates normally, close will be called for you. Again, these things aren't relevant here.