Getchar w/wout echo

Karl Heuer karl at haddock.ima.isc.com
Sat Sep 3 08:10:53 AEST 1988


In article <319 at quintus.UUCP> ok at quintus.uucp (Richard A. O'Keefe) writes:
>In article <6589 at haddock.ima.isc.com> karl at haddock.isc.com (Karl Heuer)
>proposes a   rawenable(), getrawchar(), rawdisable()   interface.
>
>>Let's begin by ignoring the issue of exactly what "raw" means.
>
>Let's not.  The original topic was reading without _echoing_, which is
>not the same thing as reading without line-editing.

Right.  Which is why I didn't define "raw"; I wanted to leave open the
possibility that it could mean "with line editing, but no echo".  Such
variants can be (and are, in my current implementation) handled via arguments
passed to rawenable().  The set of legal feature-combinations is, of course,
implementation-defined.  (It may even be empty, in which case the request
always fails.)

>>If getrawchar() is called from cooked mode, or any stdio function from raw
>>mode, the behavior is undefined.
>
>Does this mean ANY sort of stdio ...?

Good point.  Let's make it "any stdio function which applies to the raw
terminal", or something like that.

In <155 at umigw.MIAMI.EDU> and <1276 at mcgill-vision.UUCP>, steve and mouse
suggest that rawenable() and rawdisable() should be idempotent instead of
causing undefined behavior on repetition.

But it may be better to allow them to stack, instead.  (E.g. if you want to
call getpass() from within raw mode, and if getpass() is implemented using
rawenable().)  I figured it's better to leave it undefined until the details
are worked out.

Karl W. Z. Heuer (ima!haddock!karl or karl at haddock.isc.com), The Walking Lint



More information about the Comp.lang.c mailing list