> man read(2) > EBADF fd is not a valid file descriptor or is not open for reading. > Klaas is describing a condition which isn't in the manpage - ymmv.
Regarding the suggestion of EBADF, it is my understanding that the kernel must keep file descriptor 0 open (valid) even after a disconnect to prevent immediate FD reuse. If read() were to return EBADF while the descriptor is still allocated to the process, it would technically contradict the POSIX definition of that error. While the kernel could conceivably return an error like EIO or ENXIO to signal a "dead" device, treating a terminal disconnect as an "end of stream" (returning 0) appears to be the standard behavior for pseudo-terminals across most modern Unix-like systems. This ensures the stream is closed gracefully without releasing the descriptor slot prematurely. I appreciate the technical dialogue on this. On Sun, Mar 29, 2026 at 11:59 AM Thomas Dickey <[email protected]> wrote: > On Sun, Mar 29, 2026 at 11:40:56AM +0200, Stian Skjelstad wrote: > > > Actually what you're telling us is that there's a defect in (presumably > > Linux) > > > which should be documented in read(2). Once you've gotten it > documented > > in > > >the proper place (Linux manpages), then others can use the > documentation. > > > > It is normal for read() to return 0, without an error when EOF is > reached. > > This is how you detect EOF/closed on sockets and files. Should TTY behave > > differently? > > man read(2) > > EBADF fd is not a valid file descriptor or is not open for reading. > > Klaas is describing a condition which isn't in the manpage - ymmv. > > -- > Thomas E. Dickey <[email protected]> > https://invisible-island.net >
