[comp.sys.att] StarLAN login & emacs

dave@westmark.WESTMARK.COM (Dave Levenson) (05/12/91)

We run AT&T SysV/386r3.2.2 and the StarLAN UNIX Server 3.2.  When
we run the kermit terminal emulation program on an MS-DOS client
and log in to UNIX on the server, everything works find except the
EMACS text editor.

EMACS acts as if extra ^Z characters are being sent from our DOS
client to the host, or sometimes as if other control characters are
being sent.  It tries to save the buffer after every keystroke (as
if we followed every keystroke with ^X^S).  After about fifteen
seconds of inactivity, it suddenly exits to the UNIX shell, without
saving the buffer, as if we had typed ^Zn.

Other interactive software, such as vi, FACE, and such work just
fine.  What is special about the way emacs talks to its terminal?
What is special about using Starlan in this way?  Emacs works
find from the UNIX system console, or from terminals who log in
over tty ports.

Thenks.

-- 
Dave Levenson			Internet: dave@westmark.com
Westmark, Inc.			UUCP: {uunet | rutgers | att}!westmark!dave
Warren, NJ, USA			AT&T Mail: !westmark!dave
[The Man in the Mooney]		Voice: 908 647 0900  Fax: 908 647 6857

les@chinet.chi.il.us (Leslie Mikesell) (05/19/91)

In article <3378@westmark.WESTMARK.COM> dave@westmark.WESTMARK.COM (Dave Levenson) writes:
>We run AT&T SysV/386r3.2.2 and the StarLAN UNIX Server 3.2.  When
>we run the kermit terminal emulation program on an MS-DOS client
>and log in to UNIX on the server, everything works find except the
>EMACS text editor.

>EMACS acts as if extra ^Z characters are being sent from our DOS
>client to the host, or sometimes as if other control characters are
>being sent.  It tries to save the buffer after every keystroke (as
>if we followed every keystroke with ^X^S).  After about fifteen
>seconds of inactivity, it suddenly exits to the UNIX shell, without
>saving the buffer, as if we had typed ^Zn.

The starlan tty emulation is streams based and handles a read()
with O_NDELAY set and no data available by returning a -1 (as
per STREAMS instead of 0 (as a tty would).  Emacs doesn't check.

The fix is to find the read() in keyboard.c and make it treat a
negative return as if it were 0.  This may be fixed in the current
version, though.  Rn will have the same problem, and there the
read() is hidden in a couple of macros.

>Other interactive software, such as vi, FACE, and such work just
>fine.  What is special about the way emacs talks to its terminal?

It sets O_NDELAY for non-blocking reads - you may have shells running
in other windows, etc.

>What is special about using Starlan in this way?  Emacs works
>find from the UNIX system console, or from terminals who log in
>over tty ports.

Setting the termio structure VMIN and VTIME fields to 0 to get
non-blocking reads doesn't work at all, and setting O_NDELAY
on the file descriptor makes reads return -1 when no data is
available.

BTW, if you haven't already noticed, you have to remove the "xt"
capability from the AT386 terminfo entry to make EMACS work right
on the 386 console.

Les Mikesell
  les@chinet.chi.il