Odd Terminal Behavior

[Dan Mercer]

In article <720 at npdiss1.StPaul.NCR.COM> mercer at 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 at 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 at npdiss1.StPaul.NCR.COM (Dan Mercer)
"MAN - the only one word oxymoron in the English Language"