There's no need for conspiracy theories about adding delays. CR and LF were just separate functions and it's useful for them to be separate. CRT terminals (or emulations thereof) still work the same way. You have to send CR and LF to a VT100 to get the cursor to both move to the left margin and then go to the next line down.

The Unix stty command lets you set cr0/1/2/3 modes for inserting NUL characters after a CR for exactly this reason, to give the carriage time to return on your printing terminal.

Back in the eighties I worked in the military with teletypes. Some examples are:

https://www.radiomuseum.org/r/siemens_fernschreiber_t37.html https://www.cryptomuseum.com/telex/siemens/t100/index.htm https://www.camion-militar.com/spa/item/ART02979.html

There were also other makes, like Olivetti.

They were connected to various networks, e.g. military, the civil Telex network or the ICAO AFTN network.

https://en.wikipedia.org/wiki/Telex https://en.wikipedia.org/wiki/Aeronautical_Fixed_Telecommuni...

They all used a 5 bit character set Baudot/ITA2: https://en.wikipedia.org/wiki/Baudot_code (I can still read a paper tape message directly from the reel)

As these teletypes were quite slow (typically 50 baud) and mechanical, the procedure was for line shifts to always be CR CR LF. The reason for this is to allow for the carriage (printing head) to have time enough to move to the start of the line before the line feed.

This was enforced in the procedures, so you might end up with a rejected message if you did not do it properly.

When computers were introduced in the various networks, ITA2 was converted to ASCII and some of these restrictions were relaxed a bit.

What a coincidence to see CRLF discussed in HN front page, this bit me just yesterday!

While using the aws cli tool on Linux (the Docker containerized version) with the "text" output format, it turns out each output line ends with CRLF ("\r\n") instead of simply LF ("\n") as is common for any Linux cli tool, so I had to add a post-process step in my commands to remove CRs (a chained call to tr -d '\r'). Otherwise, my bash variables would end up containing those pesky carriage returns, and debug logs would show up unexpectedly bizarre.

In retrospect it's obvious what happened, but it got me confused for a good while. Why would it output CRLF at all? Also of course, not a single mention of this in any of the docs I was reading.

My first "computer" was a thermal paper terminal, with modem-phone coupler to dial-in to Compuserve (like $6 an hour after 6pm with minimums)

The separate actions of CR and LF were definitely important.

PDP-11 at school also was a paper terminal with same importance.

It's really amazing how far we've come considering what everyone has in their pocket.

It's a dreadfully common story: some ugly hack which was necessary at the time persists for decades (or centuries, in the case of legal/social systems), because nobody can really be bothered to change it.

The extra file size is not much of an issue, but it does mean we still require stupid workarounds with Git and anything else that needs to handle cross-platform plaintext.

I'm a little skeptical. Equipment from this era was designed by slide rule and sent to draftsmen to draw up and send down to the factory floor. The solution to problems was more power.

I would imagine some wily old programmer knew commands would be latched, and maybe as maintenance fell behind, the CR would lag a little, but could be trusted to complete. Better to do CR LF than LF CR. but they both have to happen.

I dunno. Maybe this model sucked. But every teletype I've ever used was kinda scary, those things will take your fingers off. They're power tools capable of violence. I'd guess, if you pulled out the maintenance guide, and applied proper lubrication, and replaced wear parts, it wouldn't miss those deadlines. I guess you might need to pull out the schematic and verify the electronics are still in spec.

I mean, yeah, the author has a point, but I'd believe it's a wear issue that this teletype doesn't reliably return in time.

HTTP also uses CRLF but the spec is flexible I think.

Still most if not all implementations use it.

That is alot of bytes when you sum them up.

Also CRLFCRLF is used to demarkate end of headers and chunks.

You couldn't do overtype without them being distinct. I think It's that simple.

> CR and LF are used for each new line.

The author's insistence on calling CR+LF "new line" only serves to confuse.

LF is line feed, thus new line. The CR is to readjust the write head back to the starting position.

Remarkably uninteresting.

Next: Let us discuss what the Unicode Character 'REVERSE LINE FEED' (U+008D) is good for.

And hopefully a short future!