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