Xref: utzoo comp.sys.ibm.pc.misc:6534 comp.dcom.lans:7268 comp.unix.sysv386:4992
Path: utzoo!utgpu!watserv1!watmath!att!emory!swrinde!elroy.jpl.nasa.gov!ncar!midway!gargoyle!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.sys.ibm.pc.misc,comp.dcom.lans,comp.unix.sysv386,news.software.rn
Subject: Re: Starlan MS-DOS client doesn't like RN
Message-ID: <1991Feb15.151409.1304@chinet.chi.il.us>
Date: 15 Feb 91 15:14:09 GMT
References: <1991Feb14.174210.5636@ms.uky.edu>
Distribution: na
Organization: Chinet - Chicago Public Access UNIX
Lines: 66

In article <1991Feb14.174210.5636@ms.uky.edu> kherron@s.ms.uky.edu (Kenneth Herron) writes:
>Sorry to post to so many groups; there's no one group devoted to starlan
>and there's more than one approach to the problem.
>
>I'm a technical consultant for some academic sites running Sysv/386 3.2, 
>scattered over several states.  One of these sites has installed C news
>and rn (patchlevel 47, I believe) from installation kits I've put 
>together.  Most of the users of this machine use a DOS machine to connect,
>via a starlan client.  The DOS starlan software apparently included a
>version of kermit which can connect over the network, and a terminfo
>description called "kermit" to go with it.

>The problem:  Rn works fine from the 6386 console, but goes crazy when
>run from a terminal session on one of the DOS systems.  From the
>description, it appears that rn sends lots of nulls and possibly other
>characters that the DOS end can't handle.  We've tried other terminfo
>files, including simple ones like "tty" and "printer"; they all produce
>different but no better behavior.  On a couple of tries, rn has acted
>as though commands were typed when they weren't, so the DOS end may be
>generating false keystrokes as well.  The behavior also changes when they
>use -T or -v when starting rn.

The problem is on the unix side - the same thing happens if you use
cu to connect over starlan from another unix machine.

The Starlan tty emulation is STREAMS based and returns the STREAMS-flavor
return value from a read() when you have set the O_NDELAY flag and
no data is available.  Personally, I think that when you push the
tty emulation module on a stream you should get the tty-flavor of return
value, but it's been this way for years now.  Apparently the developers
don't read news with rn...
See read(2): return from tty device == 0, streams == -1.

>They've never seen anything like this with any other software, including
>vi.

GNU emacs will do it as well.  

>1)  Has anyone seen a problem like this?  Better yet, has anyone
>    solved it?

The work-around is to check the return value from read for negative
values before trying to use the value as a valid count of returned
characters.  This is straightforward in emacs, but as I recall the
tty read() in rn is hidden in a couple of macros and you either
have to make a new function or use a global variable as a temporary
value.

>3)  Is there another news reader available that doesn't try to be
>    so cute with the terminal?  I'd like to avoid nn because of the
>    database it requires.

As long as you are changing things, you should look at trn,  being
based on rn it will probably need the same fix, but the indexing
really speeds up news reading and the threads database is not as
large as nn requires.

>Please reply to me rather than post; I'll summarize and post if 
>anyone else is interested (yeah, right).

This comes up at least couple of times a year and probably bothers other
people that don't post about it, so I'm posting in hopes that it will
embarass AT&T into fixing the bug in tty emulation.

Les Mikesell
  les@chinet.chi.il.us