INKEY$ [Was: printf, data presentation]

[Robert Claeson]

A discussion about a BASIC-derived INKEY$ function that reads the
keyboard and returns the next character if one is available, or returns
NULL or EOF otherwise. Some people thinks such a function should be
in the ANSI C standard.

To this, Chip Rosentahl (chip at vector.uucp) responds:
> ...Such a procedure is generally used
> for busy loops, and this is a bad idea.

...to which I completely agree. He then goes on to write:

> If you are waiting for a keystroke, then use c_cc[VMIN]=1.

...which is specific to System V. The intent was to standardise on a
system-independent interface to that function.

> If you are waiting for a one of a number of asynchronous events,
> then fork processes to block on the various events and signal the
> parent to handle it.

This is generally a good idea, but easily becomes system dependent as
well. This technique is most common in System V and slightly less
common in BSD (where the select system call can be used in most cases)
and uncommon in most other operating systems.

> Since busy waiting is a bad idea, so is formalizing it in a standard.

Agreed. But what about having a function that returns the status of the
input queue (or possibly the number of characters waiting in the input
queue) and another function to do a blocking, single character read?

Or, even better, have a system-independent interface to various mode
setting operations. I think this is what the termios calls in the POSIX
draft standard are all about.

One can in general not cover all types of input devices (an asyncronus
terminal is much differnet from a punched-card reader), but it would
certainly be possible to define a system-independent interface for a
certain class of terminals.

-- 
Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden
"No problems." -- Alf
Tel: +46 758-202 50  EUnet:    rclaeson at ERBE.SE  uucp:   uunet!erbe.se!rclaeson
Fax: +46 758-197 20  Internet: rclaeson at ERBE.SE  BITNET: rclaeson at ERBE.SE