4.3 telnet handling of newline

Charles Hedrick (hedrick@topaz.rutgers.edu)
Sat, 8 Aug 87 20:56:28 EDT

As far as I can see, the Unix implementors have failed to note that
there are in effect two different end of line conventions in Unix,
conventions for files and those for terminals. They are turning
telnet NEWLINE into <LF> because <LF> is what you put in a file to
indicate an end of line. The problem is that telnetd is feeding its
output into a pty, and pty's are terminals. On a terminal, we expect
a user to type <CR> to indicate end of line. This is why there is a
special kernel mode to map one convention into the other by turning
<CR> into <LF>. That allows naive programs to treat a terminal like
any other file, and to see <LF> as newline. However when a program
goes into raw mode, it see what is actually typed, and so it needs to
be prepared to handle the device-dependent terminal conventions. Thus
raw-mode programs expect to find <CR> as end of line, since that is in
fact the end of line convention used by terminals. This is completely
consistent with the rest of Unix, where by default, there is a uniform
model for all device types, but it is possible to set up modes wherein
you see device-specific behavior. Since telnetd is in effect typing
on a terminal, it is going to have to do things in a device-dependent
way, and issue a <CR> for NEWLINE.

Pragmatically, it probably makes sense to do this conversion in
two stages. All 4.3 implementations should immediately change telnetd
to turn both <CR><LF> and <CR><NUL> into <CR>. Only a <LF> should
be turned into <LF>. I don't see any way that this change can break
things. And it will allow people to run Emacs and other terminal-
dependent software when connected from implementations that do things
the right way. Unfortunately, the matching change, which is fixing
telnet to send <CR><LF> (telenet NEWLINE) when the user types <CR>,
may have to be delayed until a site has updated all of its copies of
telnetd. The problem is if a fixed telnet talks to a broken telnetd,
we will be back into the situation where you can't run Emacs. One
user suggested an option to select which behavior you want. I'm sorry
to say that this may really be necessary, or we can dream up a hack
(of a sort that is in fact already in telnetd) for determining
automatically whether the other end is running a broken copy of telnetd,
and adjust accordingly.

The most helpful thing would be for Berkeley to make an official
announcement that telnetd is regarded as broken and should be fixed.
We will attempt to issue SPR's against all of our supported Unix
implementations anyway, but it will be a mess if Berkeley persists in
maintaining that no fix is needed, while most of the users are
convinced that one is. Since the fixed to telnetd it to accept
connections from either style of telnet, this can't possibly lose
anything, except for the ability to have hitting the CR key put
LF into a pty at the other end. And I can't figure out any practical
use for that.

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