Xref: utzoo comp.lang.c:15203 comp.unix.wizards:13855
Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!pacbell!att!ihlpl!knudsen
From: knudsen@ihlpl.ATT.COM (Knudsen)
Newsgroups: comp.lang.c,comp.unix.wizards
Subject: Re: printf, data presentation
Summary: Where is inkey() fcn?
Keywords: printf, terminals, fixed format screens
Message-ID: <8332@ihlpl.ATT.COM>
Date: 4 Jan 89 18:59:03 GMT
References: <19@xenlink.UUCP> <731@picuxa.UUCP>
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 32

Speaking of libraries and interactive screen programs,
it strikes me as criminal negligence that hardly any C standard
libs include the inkey() function, which means "check whether
a char has been typed on the keyboard; if so, return it;
else return \0 (or whatever).  DO NOT BLOCK."

Even a blocking version (that would return a char once typed,
without waiting for a newline) would be useful.

Most OSes make the inkey() function possible, but hardly easy.
I figured out how to do it in OS9, and someday I may borrow
a chapter 7 of the sys-adm's U**X manual long enuf to write
one for System V.  I know it takes a lot of ioctl() bashing.
I have also done the blocking version in U**X, using fcntl().

My point is that some guru should have figured out how to do
inkey() on the OS in question and put this in the library.
Then ordinary programmers wouldn't have to figure it out
for the zillionth time.
[Given that U**X was born on DEC machines with full-duplex
TTYs, I'm surprised that the C library didn't get inkey()
early on.  I guess VI and EMACS didn't come till much later.]

Anyway, it's the need for such functions that often keeps interactive
applications from using the buffered (f-names) I/O fcns.

Ironically, inkey() is built into every "toy" computer with
BASIC in ROM.  The joys of having no OS...
-- 
Mike Knudsen  Bell Labs(AT&T)   att!ihlpl!knudsen
"Lawyers are like nuclear bombs and PClones.  Nobody likes them,
but the other guy's got one, so I better get one too."