On Sun, Mar 29, 2026 at 12:15:45PM +0200, Klaas van Aarsen wrote: > > 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.
either it's closed, or it's not.
ncurses doesn't reopen it.
Since ncurses doesn't reopen it, I don't see any reason why the dangling
symlink would be relevant.
Checking errno after the failed call would be more useful than making
a signal handler :-)
> 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.
If you're able to reproduce the problem, and modify the program to report
the errno value, then we can discuss whether the errno value matches the
expected behavior.
> 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.
ncurses is using the read directly (stream usually refers to things
opened via fopen).
initscr (used in this program) calls newterm
if (newterm(name, stdout, stdin) == NULL) {
newterm copies the file descriptor:
SP_PARM->_ifd = fileno(_ifp);
and after that, it ignores any buffering that the caller may have on that
file descriptor. ncurses never closes that file descriptor. If you got
EBADF, then that would indicate that the connection was closed (either
end of a connection can close it).
> 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
> >
--
Thomas E. Dickey <[email protected]>
https://invisible-island.net
signature.asc
Description: PGP signature
