Re: telnet CR processing, bridge comm servers and TWG telnet


John T. Wroclawski (JTW@XX.LCS.MIT.EDU)
Tue 11 Aug 87 04:21:04-EDT


Summary: Chuck Hedrick's recent letter hit the nail on the head.

    From: barmar@think.com (Barry Margolin)
    Subject: Re: telnet CR processing, bridge comm servers and TWG telnet

    In article <In article <109@quick.UUCP> In article <109@quick.UUCP> srg@quick.UUCP (Spencer Garrett) writes:
> You hit <RETURN>
> The Bridge box sends \r\n

    You said this twice in your message without justifying it. The key is
    labeled RETURN, which is generally taken to be a synonym for CR. The
    TELNET spec says that CR should be represented in NETASCII as CRNUL.
    Why should the Bridge box assume that CR is NEWLINE?

Because it is the character most often sent by the key that most
people using terminals likely to be hooked to Bridge boxes use for
EOL, and you have to have some way to send a NEWLINE.

However, it doesn't really matter -what- the bridge box sends. The only
thing that matters is that the terminal<->NETASCII<->machine transformation
be invisible.

For unix-like systems this is easily achieved by having the server telnet
translate incoming CR-LF and CR-NUL to CR, and incoming LF to LF. This
result is then stuffed into the PTY, where normal terminal processing
(CRMOD) takes care of the rest, including your objection below. (Which
-is- a problem if CR-LF translates to LF, as Spencer suggested.)

> telnetd converts \r\n to \n and feeds it to the pty
> telnet reads \n from its tty (pseudo-tty, but it shouldn't matter)
> telnet sends \r\n through its tcp stream to the vax
> the vax should convert \r\n to whatever it wants for EOL

    What if the program on the VAX wants to see the raw characters that
    the user typed, which happens in programs such as EMACS?...

-------



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:38:49 GMT