When I connect by phone to Grex, the lynx program works right.
When I connect by telnet, the lynx program adds a linefeed that
throws off the display.  All other programs work right when I
telnet in...why does lynx do that?

26 responses total.

This response has been erased.

Valerie, I *did* check my settings (stty -a or stty all, whichever it is
here).  They were absolutely identical, but vi still gave the same symptoms.
(I didn't see anything in the environment that should relate; I checked
the termcap one, I think.)

Same symptoms here.  My term program only does vt102, not vt100
as Merit insists upon (it won't regognize vt102), could that be
part of it?

This response has been erased.

I use Bourne shell.

This response has been erased.

I don't have any other way to telnet in, so I do.  (Remmers, who says he
never has these problems, said (on this morning's walk) that he doesn't go
through Gopher.  Hard to see just what difference that should make, but
it would be interesting to know.

I use csh, and I can only telnet in via msu-gopher.

And I use sh.

Is there anyone here who has seen these symptoms & does not telnet in through
Gopher?  Or, if you normally telnet in otherwise & have not seen these
symptoms (but use vt-family emulation, I guess), consider trying the
Gopher route & see what happens.

Hm.  Over the net, I think we've all noticed the lags in character echo
after typing.  Is it possible that cursor-addressing sequences are getting
broken up after the lags & garbled?  Seems unlikely - the symptoms in vi
seem too consistent for this kind of erratic phenomenon.

The only symptom I have when I connect via msu-gopher is that I can't seem
to send an interrupt to Grex.

I connect to Grex via straight telnet (no MSU-Gopher) and have never
seen this problem.  How do you connect to the MSU Gopher?

Pretty much like this:

1) Call Merit at 939-3370
2) From Which Host? I type msu-gopher
3) Then I follow the menus to Grex.

I personally have never used the dial-in's here.  I have always used the
internet connection.  But the systoms that you are having seem very
similiar to something that I experienced a few machines ago.  I think I
was on an ultrix or apollo then, and I always seemed to get out of sync
with where my cursor thought it should be, and where it actually was.  I
finally narrowed the problem down to the fact that my term setting was
off.  The emulator program I was using was set up on a windowed
environment, so I could resize my screen to whatever I wanted.  This was
ok, so long as I didn't run a program that uses some sort of screen
manager package (ie curses).  When I did this, and the server machine
didn't realize what size my emulator was set at, it got confused and put
the cursor at the wrong spot.

Uh... I think.

Anyway, to get rid of the problem, first off make sure that you term
setting is correct.  Then make sure that all of the stty settings are the
correct for that setting.  You will most likely find something that is out
of whack.

I call 998-1302, at the Which Host? prompt I type "msu-gopher",
login as gopher, select 13,5,7, and 7, then login here.

That's when lynx doesn't work right.  It may be a curses related
problem.  But I doubt it's my software, since it works perfectly
when I dial direct to Grex.

(Of course my short-term solution is to dial in when possible,
but I'd like to get a faster modem for internet connections and
would want to use the msu-gopher connection to run lynx here.)

This response has been erased.

This response has been erased.

Okay, I'm am now logged in via msu-gopher, and was having the same
problems other people were describing -- e.g. parts of a line being
erased during "long" cursor movements, as with the "w" command for
jumping to the next word.  Similar problems in GNU emacs too.  I
never had this problem when dialing or telnetting direct to grex.

I think the problem is with the TAB character.  If vi or emacs
thinks your terminal recognizes tabs, they send out tab characters
to do fast cursor movement.  However, when connected to msu-gopher,
some link in the connection evidently converts tabs to spaces,
resulting in screen erasing.

The solution is to type the command "stty -tabs" right after you
log in.  This tells the tty driver that your terminal can't do
tabs, and then vi, emacs, & friends will never output them.  This
seems to have fixed the problem for me.

This response has been erased.

re#17- I thought it had something to do with the 'lag' time.  I already have
my pager set to more.   Most of the time it's not a problem to not be able
to do the interrupt, but say I do 'last' and then I have to wait like 5 mins
for it to finish displaying.  I know I could do a last | more, but youtend
to forget to do th@at.

This response has been erased.

You could put 

        alias last "\last | more"

in your .cshrc file.  (Or maybe it require two backslashes: \\last)

You can also do last -number, where number si the number of lines you want
it to display.

Hmmm... yup, I tried to go in thru the msu gopher, and I got the same
problem.  Goes to show what happens when you talk before you think. 

I haven't tried   stty -tabs   yet, but *thank* *you*, John!!!!!!!!!!!!!!

I agree with davel.  *Thanks* John!

Response not possible - You must register and login before posting.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss