Reputation: 6395
Suppose I call *nix select(read_fd, ...)
with a read descriptor that is not obtained from a file, but is a controlling terminal of a process. When this returns that means the descriptor has something to read for me.
The man page for select
says it could be 0 characters in the case of EOF, so that when I call read()
I will not block but will not get any characters.
But this EOF effect cannot happen for a controlling terminal file descriptor, can it?
Upvotes: 0
Views: 35
Reputation: 20842
Yes it can. There are several scenarios, but in short, a controlling terminal can be anything in UNIX. You can start a process under a pty (pseudo-tty) and plug it into another process as its controlling terminal. If that process or pty goes away, your file descriptors will be closed and you'll get EOF. All that is required is for the descriptors of a process to be mapped to 0, 1 and 2. Those could be a network socket, a pipe, a file, etc.
A process can also close its descriptors to sever the connection to its controlling terminal, so I'm sure a read would then return 0.
Its been literally 20 years since I wrote a telnetd server, so I'm going off of distant memory, but I'm pretty sure I'm correct here. If my answer is too vague, a good book to refer to on this stuff is W. Richard Steven's Advanced Programming in the UNIX Environment, it covers all sorts of scenarios, controlling terminals
, ptys
, daemons
, and select()
are covered in detail in his other book, UNIX Network Programming.
Upvotes: 1