<CR>, <LF>, and printing terminals (Was: [UFO Chicago] another very newbie 'nix question)

[Neil R. Ormos]

Nick Moffitt wrote:

> begin  John Kilbourne  quotation:

>> What are all the ^M 's that are at the ends of the lines
>> in text files I take from windows (made in gvim) and put
>> on unix or linux?  It must be some kind of newline thing;
>> do they do any harm?

> 	In the days of the old slow printer terminals, it
> was found that it took twice as long for the print head to
> swish back over to the left hand side of the page as it
> did for the head to move to the right one character.  The
> correct solution would have been to buffer your printing
> while your head moved back, but instead the practice of
> using TWO characters to represent what happens when you
> hit the Return key was started.

Distinct from the Holy War issue of whether it is proper to
*store* an end-of-line symbol as a Carriage-Return character
(<CR>), a Line-Feed character (<LF>), or a sequence of the
two, the reasons for defining and transmitting these
characters separately may be better understood in historical
context.  <CR> and <LF> were represented and sent as
separate ASCII characters for at least two reasons:
  (1) it had always been done that way (i.e., even before
      computers and ASCII); and
  (2) <CR> and <LF> are separate operations and one does not 
      necessarily imply the other.  

As to the latter reason, an example of why you would want
<CR> without <LF> was password entry on a printing terminal.
The host would prompt for the password, and after the user
had typed it and sent <CR>, the host would typically
obliterate the password by overtyping it with other
characters several times.  This required <CR> but not <LF>.
<LF> without <CR> was useful in drawing diagrams and stuff.
Most electro-mechanical printing terminals (e.g., Teletype
Model 33, IBM Model 1980 (Selectric based)), and even some
more modern terminals (e.g., LA36 "DECwriter II") did not
support a reverse line feed.

To the extent the mechanical delay associated with returning
the print head to the left margin was an issue, it was
generally resolved by having the host transmit several
non-printable filler characters (e.g., NULs) after <CR>.  It
might have been more elegant to simply delay after sending
<CR>, but at the time it was difficult to provide a
deterministic delay due to the presence of communications
processors, terminal multiplexors, or equivalent equipment
interposed between the host and the communications line.  

It might also have been more elegant (or "correct" as Nick
suggests) to buffer characters received by the terminal
while the mechanism was busy, but it was not
feasible--electromechanical terminals (e.g. TTY-33) had no
memory (well, maybe a one character register).  Some later
terminals, such as the DEC LA36, did have a buffer; the LA36
even printed at about twice its normal speed (of 30 cps) at
the beginning of lines while trying to deplete the buffer.