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]
