Cbreak or not Cbreak, that is the question ...

[Ed Nather]

[]
In moving small C programs between an IBM PC and a Vax running 4.2bsd Unix,
I have been struck by the very different way in which console I/O must be
handled.  These programs are interactive and expect single-character
commands (not echoed) from the keyboard.

Under 4.2bsd Unix I must put the tty driver into "cbreak" mode, or "raw"
mode if I want no input processing at all, then find out if the user has
typed anything, interpret it, and respond.  If I want to return to "normal"
console I/O I must discuss the matter with the tty driver again.

Using DeSmet C (an example -- other compilers for the PC have equivalent
features) I can switch between processed character input (getc() or
getchar()) and raw input by simply using a different character call;
in DeSmet C the function ci() gets an unprocessed, unechoed character
from the keyboard, co() writes one on the console screen.  I can go back
and forth between processed or unprocessed i/o very simply.  There is also
a function that tells you if a character has been typed, without waiting
for one -- *very* useful in many programs to check for "pseudo-interrupts"
during a lengthy procedure, or to provide console feedback about what the
program is doing.

I suspect these extra, "non-standard" funtion calls violate some general
religious principle about treating all devices alike, but they are *very*
useful, and I would trade Purity any day to have them available on the
Vax Unix system.

Comments?
-- 

                                 Ed Nather
                                 {allegra,ihnp4}!{ut-sally,noao}!utastro!nather
                                 Astronomy Dept., U. of Texas, Austin