Bug#458986: #458986 - Should check for EOF/EIO
On Mon, 11 Aug 2008, Samuel Thibault wrote: Thomas Dickey, le Sun 10 Aug 2008 17:24:58 -0400, a écrit : On Sun, 10 Aug 2008, Samuel Thibault wrote: reopen 458986 [EMAIL PROTECTED] reassign 458986 ncurses thanks Thomas Dickey, le Thu 03 Jan 2008 20:06:02 -0500, a écrit : procps contains two programs that use ncurses. However, it is not using ncurses for reading from the terminal - there is no instance of getch in the code. So (pointing out that if it had, I'd be explaining how other programs deal with getch's limited repertoire of return codes), it seems that the problem is entirely in procps. slabtop.c uses a select/read combination, i.e., ...and procps is the logical place to implement the fix For the original bug, yes, but for the bug I'm talking about (tputs not telling about EIO errors), it is not. Then create a new bug report telling what you want. The bug in procps will not be affected by any change that you're implying here. At best, you'll end up with the same situation that you have with getch - an ERR return that doesn't tell why it failed. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Bug#458986: #458986 - Should check for EOF/EIO
reopen 458986 [EMAIL PROTECTED]
reassign 458986 ncurses
thanks
Thomas Dickey, le Thu 03 Jan 2008 20:06:02 -0500, a écrit :
procps contains two programs that use ncurses.
However, it is not using ncurses for reading from
the terminal - there is no instance of getch in the code.
So (pointing out that if it had, I'd be explaining how other
programs deal with getch's limited repertoire of return codes),
it seems that the problem is entirely in procps.
slabtop.c uses a select/read combination, i.e.,
FD_ZERO(readfds);
FD_SET(0, readfds);
tv.tv_sec = delay;
tv.tv_usec = 0;
if (select(1, readfds, NULL, NULL, tv) 0) {
if (read(0, c, 1) != 1)
break;
parse_input(c);
}
watch.c reads via a pipe - does not read from the terminal at all.
Since it is not using ncurses for reading from the terminal,
this bug should be reassigned back to procps.
If the 458986 bug was about procps, yes. But it is not, as I said when
cloning the procps bug, Concerning ncurses, I'm a bit uneasy. In an
ideal world, it should always check for EOF and EIO in puts, tput etc,
but usually nobody checks the result of these functions... Cloning
anyway since the errors should really get reported.
I.e. as the title says, 458986 is not about ncurses reporting EOF (which
it does indeed), but about reporting an error when puts, tput, etc get
errors like EIO. Else, an application that doesn't take user input at
all would continue running even when if its terminal is gone, even if it
checks for ncurses output errors.
Samuel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458986: #458986 - Should check for EOF/EIO
On Sun, 10 Aug 2008, Samuel Thibault wrote: reopen 458986 [EMAIL PROTECTED] reassign 458986 ncurses thanks Thomas Dickey, le Thu 03 Jan 2008 20:06:02 -0500, a écrit : procps contains two programs that use ncurses. However, it is not using ncurses for reading from the terminal - there is no instance of getch in the code. So (pointing out that if it had, I'd be explaining how other programs deal with getch's limited repertoire of return codes), it seems that the problem is entirely in procps. slabtop.c uses a select/read combination, i.e., ...and procps is the logical place to implement the fix awai: assigning it to ncurses won't fix procps, nor will it achieve any useful purpose. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Bug#458986: #458986 - Should check for EOF/EIO
Thomas Dickey, le Sun 10 Aug 2008 17:24:58 -0400, a écrit : On Sun, 10 Aug 2008, Samuel Thibault wrote: reopen 458986 [EMAIL PROTECTED] reassign 458986 ncurses thanks Thomas Dickey, le Thu 03 Jan 2008 20:06:02 -0500, a écrit : procps contains two programs that use ncurses. However, it is not using ncurses for reading from the terminal - there is no instance of getch in the code. So (pointing out that if it had, I'd be explaining how other programs deal with getch's limited repertoire of return codes), it seems that the problem is entirely in procps. slabtop.c uses a select/read combination, i.e., ...and procps is the logical place to implement the fix For the original bug, yes, but for the bug I'm talking about (tputs not telling about EIO errors), it is not. Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
