Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!gorodish!guy From: guy@gorodish.Sun.COM (Guy Harris) Newsgroups: comp.unix.questions Subject: Re: VT100 terminfo problem Message-ID: <69011@sun.uucp> Date: 19 Sep 88 23:26:46 GMT References: <3340@dunkshot.mips.COM> <8521@smoke.ARPA> <68816@sun.uucp> <26146@ucbvax.BERKELEY.EDU> Sender: news@sun.uucp Lines: 43 > >>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. We all agree, but they *are* a reason to avoid "raw" mode, since it doesn't support keyboard signals. The list given was a list of conditions, all of which should be true before you use "raw" mode. Even if they are true, CBREAK mode may still be appropriate; if one of them is not true, RAW mode is inappropriate. > 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. Careful what you concede; V7 let you set the special characters. > I'm not sure the 8-bit argument for using RAW is valid either. Given that the argument was "if you DON'T want an 8-bit data path, DON'T use raw mode", it is valid. The converse, of course, doesn't follow; if you want an 8-bit data path, you need not necessarily use raw mode. > 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. SunOS 4.0 also handles this correctly. > 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... I think I know of one program - perhaps even one distributed with S3 - where it *was* stting either the ISIG or ICANON bit in "c_iflag". The names are somewhat bogus....