maa@ssc-vax.UUCP (Mark A Allyn) (11/18/90)
I am having wierd terminal behavior when I am using my terminal and modem
and trying to use VI. Here is the set up:
1. Terminal is a Tandy DT100 which emulates a VT100.
2. Modem is a DSI 9624le running at 2400 baud.
3. Modem at host machine is unknown but is capable of up to 2400
baud.
4. Host machine is a VAX780 running BSD4.3
5. I telnet to another host machine (this being a Sun Sparc 1+ running
SunOs 4.01). Note that I can only use telnet since the Sun's host
name and address is not in the host table in the VAX and rlogin
expects a host name and not a decimimal notation of an Internet
address.
6. Once on the Sun, I do the following.
a. setenv TERM vt100
b. stty 2400
c. stty cols 80
d. stty rows 24
7. I attempt to run VI or do anything else.
I think that the terminal is either getting spurous characters or there
is no control of the speed of the output of the VI or other session that
I am running. I would think that the stty 2400 should take care of that
but it appears not to. Is there something else that I have to do in order
to ensure that the buffering between the application and the terminal
is not being overloaded?
Thanks!
Mark A. Allyn phone 206-477-2937 (day) 206-526-8852 (nite)
US Mail Boeing Company
Mail Stop 8Y-03
P.O. Box 3999
Seattle Wa. 98124
Email uw-beaver!ssc-vax!ssc-bee!maa
Ham WA1SEY
Radiomercer@npdiss1.StPaul.NCR.COM (Dan Mercer) (11/20/90)
In article <3527@ssc-bee.ssc-vax.UUCP> maa@ssc-vax.UUCP (Mark A Allyn) writes:
:I am having wierd terminal behavior when I am using my terminal and modem
:and trying to use VI. Here is the set up:
:
:1. Terminal is a Tandy DT100 which emulates a VT100.
:2. Modem is a DSI 9624le running at 2400 baud.
:3. Modem at host machine is unknown but is capable of up to 2400
: baud.
:4. Host machine is a VAX780 running BSD4.3
:5. I telnet to another host machine (this being a Sun Sparc 1+ running
: SunOs 4.01). Note that I can only use telnet since the Sun's host
: name and address is not in the host table in the VAX and rlogin
: expects a host name and not a decimimal notation of an Internet
: address.
:6. Once on the Sun, I do the following.
: a. setenv TERM vt100
: b. stty 2400
: c. stty cols 80
: d. stty rows 24
:7. I attempt to run VI or do anything else.
:
:I think that the terminal is either getting spurous characters or there
:is no control of the speed of the output of the VI or other session that
:I am running. I would think that the stty 2400 should take care of that
:but it appears not to. Is there something else that I have to do in order
:to ensure that the buffering between the application and the terminal
:is not being overloaded?
:
:Thanks!
:
:
:Mark A. Allyn phone 206-477-2937 (day) 206-526-8852 (nite)
:
: US Mail Boeing Company
: Mail Stop 8Y-03
: P.O. Box 3999
: Seattle Wa. 98124
:
: Email uw-beaver!ssc-vax!ssc-bee!maa
:
: Ham WA1SEY
: Radio
Tou don't really explain what the problem is that you are having, so
it's very difficult to offer any help. It is possible that your
terminal prints nulls as spaces, which will really screw up your
terminal on a telnetted vi session. (Telnet will use NULs with
carriage returns for some screwy reason I forget - someone who sleeps
with RFC's under his pillow will, I'm sure, fill us in). I have a
PC running NANSI.SYS logged into an NCR Tower running both Token Ring
and TCP/IP. Since the Token Ring nlogin program uses the PC's native
terminal capabilities (ie ANIS.SY or NANSI.SYS) we get this problem.
The solution we found was to eliminate, as much as possible, vi's
use of carriage return by defining cr=\E[80D. Someone suggested that
it was telnet's fault for not stripping out the NULs.
--
Dan Mercer
NCR Network Products Division - Network Integration Services
Reply-To: mercer@npdiss1.StPaul.NCR.COM (Dan Mercer)
"MAN - the only one word oxymoron in the English Language"mercer@npdiss1.StPaul.NCR.COM (Dan Mercer) (11/20/90)
In article <720@npdiss1.StPaul.NCR.COM> mercer@npdiss1.StPaul.NCR.COM (Dan Mercer) writes: > >Tou don't really explain what the problem is that you are having, so >it's very difficult to offer any help. It is possible that your >terminal prints nulls as spaces, which will really screw up your >terminal on a telnetted vi session. (Telnet will use NULs with >carriage returns for some screwy reason I forget - someone who sleeps >with RFC's under his pillow will, I'm sure, fill us in). I have a Ok, so I'll follow up to my own reply - from RFC 854 The sequence "CR LF", as defined, will cause the NVT to be positioned at the left margin of the next print line (as would, for example, the sequence "LF CR"). However, many systems and terminals do not treat CR and LF independently, and will have to go to some effort to simulate their effect. (For example, some terminals do not have a CR independent of the LF, but on such terminals it may be possible to simulate a CR by backspacing.) Therefore, the sequence "CR LF" must be treated as a single "new line" character and used whenever their combined action is intended; the sequence "CR NUL" must be used where a carriage return alone is actually desired; and the CR character must be avoided in other contexts. This rule gives assurance to systems which must decide whether to perform a "new line" function or a multiple-backspace that the TELNET stream contains a character following a CR that will allow a rational decision. Note that "CR LF" or "CR NUL" is required in both directions (in the default ASCII mode), to preserve the symmetry of the NVT model. Even though it may be known in some situations (e.g., with remote echo and suppress go ahead options in effect) that characters are not being sent to an actual printer, nonetheless, for the sake of consistency, the protocol requires that a NUL be inserted following a CR not followed by a LF in the data stream. The converse of this is that a NUL received in the data stream after a CR (in the absence of options negotiations which explicitly specify otherwise) should be stripped out prior to applying the NVT to local character set mapping. >PC running NANSI.SYS logged into an NCR Tower running both Token Ring >and TCP/IP. Since the Token Ring nlogin program uses the PC's native >terminal capabilities (ie ANIS.SY or NANSI.SYS) we get this problem. >The solution we found was to eliminate, as much as possible, vi's >use of carriage return by defining cr=\E[80D. Someone suggested that >it was telnet's fault for not stripping out the NULs. >-- >Dan Mercer >NCR Network Products Division - Network Integration Services >Reply-To: mercer@npdiss1.StPaul.NCR.COM (Dan Mercer) >"MAN - the only one word oxymoron in the English Language" -- Dan Mercer NCR Network Products Division - Network Integration Services Reply-To: mercer@npdiss1.StPaul.NCR.COM (Dan Mercer) "MAN - the only one word oxymoron in the English Language"