input ready under UNIX ??!!??
Chris Torek
chris at mimsy.UUCP
Thu Oct 27 04:40:58 AEST 1988
>In article <771 at necis.UUCP> rbono at necis.UUCP (Rich Bono) writes:
>>HELP!! how can one (if at all) find out (non-destructivly) if there is
>>any input waiting to be read from stdin??? ... Clearing ICANON ...
In article <547 at poseidon.ATT.COM> psrc at poseidon.ATT.COM (Paul
S. R. Chisholm) writes:
>First of all, it sounds like a good idea to package this in a single
>routine with a portable interface. You may have to entirely rewrite
>the routine to get it to run under the UNIX(R) operating system, but
>it would be called the same as under MS-DOS.
Good advice, especially since this is an O/S question and not a C
question (so what is comp.lang.c doing in the header?). I have
redirected followups.
Fortunately, there was a clue (`ICANON') in the above as to which O/S
Rich Bono was using, namely either SysV or SunOS 4.x (as opposed to the
One True Unix%).
-----
% 4.1BSD, no, wait, I meant 4.2BSD, no, make that V8, er, V9, I mean . . .
-----
[Various approaches deleted]
>[fcntl O_NDELAY] (If you're paranoid that the child might die, dup(2)
>file descriptor zero, close(2) file descriptor zero, dup() the copy
>(which will become file descriptor zero), and close() the copy. The
>child process now has its own file descriptor for standard input.)
This will not do any good: dup()ed file descriptors share the same
file table entry, and the O_NDELAY flag sits in the file table entry.
Remember, child processes get dup()s of the parent's descriptors in
the first place.
Finally, under 4.{2,3,3-tahoe} BSD, you can use select() after setting
the terminal to `cbreak' mode; this acts more or less exactly like kbhit():
#include <sys/types.h>
#include <sys/time.h>
kbhit() {
int in = 1; /* really should use fd_set */
static struct timeval zero;
return (select(1, &in, (int *)0, (int *)0, &zero) == 1);
}
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris at mimsy.umd.edu Path: uunet!mimsy!chris
More information about the Comp.unix.questions
mailing list