-> What I want to do is display a constantly-changing image on the
-> screen while constantly checking for keyboard input.
->
-> One method that comes to mind is to simultaneously launch two
-> asynchronous threads:  one for getting keyboard input and the other
-> for displaying on the screen.  Will the thread waiting for keyboard
-> input issue a system blocking call thereby halting the changing
-> screen display?
->
-> I'll be working in ANSI-standard *nix so I can't use any of the neato
-> DOS tricks like checking the keyboard buffer.

     It is built into the OS Shell.  Issue an input command and see &&,
||, WAIT, SLEEP, BREAK, INTERRUPT, SIGNAL, ON ERROR, ON KEY, et cetera.
(Every shell has something different.)  I think BASH even has a timed
entry like DOS CHOICE....  I *HATE* animated prompts like "spinning
cursors" and "clock quadrant quarter-squares" animations. 
They fill up
my backscrolling/backpaging screens buffer with page after page of
garbage characters.  *YECH!*


-> Another question I have about *nix keyboard-input routines deals with
-> the Enter key.  I know that DOS has getch() and getche() which get
-> single character keyboard input without the user having to press
-> ENTER.  Unfortunately, these are specific to Intel machines (most of
-> which use DOS related OSes).  Does the *nix world have something
-> similar or does the user _always_ need to press ENTER after typing
-> keyboard input?

     No.  Of course not.  I am surprised that you would even ask this.
The conditioning of the line I/O -- whether or not it is line buffered
for terminal input, channel buffered for a block device, or takes
character input one byte at a time, depends on how you "(S)et the
(T)ele(TY)pe input/output".  Do a MAN STTY.  See 'raw' for performing
"raw character I/O". See 'cooked' for how to "unraw"
the I/O back into
line conditioned input.  See 'sane' for when your terminal goes stark
raving mad and prints nothing but gibberish.  See 'maptty' and 'mapchar'
and 'mapchan(nel)'... (only if you have them... some UNIXes don't...).

     The UNIX "STTY" command is essentially a "software
modem".  You can
set the job I/O Stream any way that you like, buffer it or not buffer
it, tack on Carriage Returns and Line Feeds or remove Carriage Returns
and Line Feeds, translate filter it with TR or PERL or any of the custom
filters for things like daisy-wheel teletypes.  UNIX lets you do
anything straight from the OS.  You do not have to bypass the horrid OS
in order to do "hardware cheats".  The OS is **GREAT** !  Embrace it !

What made me furious was when some idiot programmer "improved" the
MS-DOS version of "LESS" by removing the OS calls and installing --
instead -- the oh so much better Bordland CONSOLE routines that directly
called the console hardware, thereby **REMOVING** the ability to
redirect LESS out of a COMx: port to a Serial Printer.  ARGH!  The
"whole point" of UNIX software tools is that you can direct jobstream
I/O from *ANYTHING* and to *ANYTHING* !

--- ViaMAIL!/WC v1.60d