hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) (08/09/87)
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.