tallman@dspo.UUCP (05/09/85)
The new 'rn' has a bug. On terminals where parity is used, the top bit
of a character read in raw mode is set for parity. More than half of
the commands done in the article preview stage did not work until I
made this change in articles.c :
129c129
< c = getchar();
---
> c = getchar() & 0x7f;
--
C. David Tallman - dspo!tallman@LANL or {ucbvax!unmvax,ihnp4}!lanl!dspo!tallman
Los Alamos National Laboratory - E-10/Data Systems
Los Alamos, New Mexico - (505) 667-8495guy@sun.uucp (Guy Harris) (05/10/85)
> The new 'rn' has a bug. On terminals where parity is used, the top bit > of a character read in raw mode is set for parity.... The new 'rn' has another bug. On terminals like a VT100 in smooth-scroll mode where you *must* support XON/XOFF flow control, there is a good chance that it will **** all over your screen under certain circumstances. Fix: use CBREAK mode, not RAW mode. CBREAK mode was put into UNIX specifically for this kind of thing. RAW is intended for binary data transmission (UUCP's 'g' protocol uses it, for instance). 'rn' neither uses the eighth bit of characters from terminals that can generate them nor the XON or XOFF characters for any purpose, so it doesn't need to run in RAW mode and shouldn't do so. Guy Harris
david@ukma.UUCP (David Herron, NPR Lover) (05/11/85)
There's another "little" problem with this "new" rn. It doesn't work
with 2.10.3 (I'm alpha testing it here). The problem is with the
routine which reads the active file to generate the default .newsrc
file. It mis-reads it (only looks for 2 fields per line) and generates
a VERY bogus .newsrc file.
The same problem should also appear with 2.10.2.
--
--- David Herron
--- ARPA-> ukma!david@ANL-MCS.ARPA or ukma!david<@ANL-MCS>
--- or david%ukma.uucp@anl-mcs.arpa
--- Or even anlams!ukma!david@ucbvax.arpa
--- UUCP-> {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!david
--- {ihnp4,decvax,ucbvax}!cbosgd!ukma!david
"It's *Super*User* to the rescue!"