Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!columbia!rutgers!ucla-cs!zen!ucbvax!ultra.UUCP!wayne From: wayne@ultra.UUCP (Wayne Hathaway) Newsgroups: comp.protocols.tcp-ip Subject: Re: Berkeley (not wollongong!) telnet and new line processing Message-ID: <8707232004.AA05747@lear.ultra.com> Date: Thu, 23-Jul-87 16:04:39 EDT Article-I.D.: lear.8707232004.AA05747 Posted: Thu Jul 23 16:04:39 1987 Date-Received: Sat, 25-Jul-87 13:49:34 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 38 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 key. It had "INDEX," which did a , and it had "RETURN," which did a combined (actually the EBCDIC "newline" character); the only way to output a naked 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 () into EBCDIC "newline," and naked 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 . 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: typey-typey-typey-typey-backspace-backspace-backspace-backspace-index typey-typey-typey-typey-backspace-backspace-backspace-backspace-index typey-typey-typey-typey-backspace-backspace-backspace-backspace-index typey-typey-typey-typey-backspace-backspace-backspace-backspace-index 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 408-922-0100 * There was at least one other name for the 2741 that also started with "Mother." Fun gadget ...