VT100 terminfo problem

[Marc Teitelbaum]

In article <8527 at smoke.ARPA> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <68816 at sun.uucp> guy at gorodish.Sun.COM (Guy Harris) writes:
>>The *ONLY* time "raw" mode should be used for "full-screen" interactive
>>applications are those times when:
>
>Add another one:
>	5) keys must not generate signals.
>

No - keyboard signals are not a reason to avoid CBREAK.  Traditionally
this is handled in BSD by setting CBREAK and disabling all special
characters.  I concede this would have been true in V7, but special
characters have been settable since 3BSD.

There have always been two schools of thought here.  The first one
thinks a raw i/o path should be just that - completely raw, and
the second school (the practical school) realizes that many functions,
such as flow control and interrupts, just can't be ignored and
usually must be done locally.  And it's unfortunate that games must
be played with flow control and interrupts over network connections,
but they're necessary.

I'm not sure the 8-bit argument for using RAW is valid either.
Setting both LITOUT and PASS8 in addition to CBREAK and disabling
special characters might be sufficient for applications which want
8-bit, a fairly raw i/o path, and which still have to process flow
control locally.  This still won't cut it for people who use ^S in
emacs - c'est la vie.  And programs which really want to transfer
data transparently should still use RAW - but these programs aren't
typically connected to terminals (or people).

Also, be aware that using PASS8 makes quoting input characters
impossible (either literal next or '\').  In fact, trying to quote
a character will just succeed in setting its 8-th bit.  This is a
bug without a one-line fix - luckily the next release of BSD fixes this.

>As I'm sure Guy knows, 7th Edition-based tty handler modes were just
>not sufficiently fine-grained and orthogonal.  The USG tty handler
>was a considerable improvement in this regard, and any POSIX-conforming
>implementation will be.

No argument here, however i still can't believe the ISIG and ICANON
flags are in the *l*flag element.  And considering these flags are
bit masks which can't be type-checked at compile time, this is a real
blunder.  I can see lots of new termio(s) programmers thinking ISIG
and ICANON belong in the iflag...

Marc

-------------------------------
Marc Teitelbaum			+1-415-643-6448
457 Evans Hall
Computer Systems Research Group,  CSRG / DEC
University of California
Berkeley, CA 94720