Re: Berkeley (not wollongong!) telnet and new line processing

Wayne Hathaway (ultra!
Thu, 23 Jul 87 13:04:39 PDT

Apropos of not much more than "Nothing new under the sun," a small war
story about TELNET end-of-lines. Back about 15ish years ago I had the
dubious pleasure of trying to shoehorn an IBM system into the ARPANET
world. In particular, we used the IBM 2741, a half-duplex Selectric
typewriter ("Mother of the TELNET go-ahead"*). Among the 2741's
endearing qualities was that it had no <CR> key. It had "INDEX,"
which did a <LF>, and it had "RETURN," which did a combined <CR><LF>
(actually the EBCDIC "newline" character); the only way to output a
naked <CR> was to backspace all the way to the beginning of the line!

In actual operation, this caused no real problem, because of course my
user TELNET was smart enough to translate TELNET end-of-line
(<CR><LF>) into EBCDIC "newline," and naked <CR>s were pretty rare.
Except in one case: good old Multics (or at least one generation of
Multics TELNET), which for some unknown reason insisted on ending
every line with <CR><NUL><LF>. Decidedly nonconforming for sure, but
completely transparent to almost every other ARPANET host, so why
change? Anyway, whenever I logged into Multics from a 2741 I got the
following behavior:


Ad nauseum. But the most interesting thing was that in spite of
everything taking more than twice as long (plus shaking everything off
the typing table), the output ended up being exactly correct! Amazing
what can pass for "interoperability" ...

            Wayne Hathaway ultra!wayne@Ames.ARPA
            Ultra Corporation
            2140 Bering drive with a domain server:
            San Jose, CA 95131 wayne@Ultra.COM

* There was at least one other name for the 2741 that also started
  with "Mother." Fun gadget ...

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