Hacker News Reader

Comment by aktau | Hacker News Reader

Now I'm curious. How is \r\n more right than \n or \r? In which situations? Advantages? Disadvantages?

If you send it in raw format to a Teletype, it'll print correctly...

Other than that, I don't see it being any more right. But it is a convention that is far older than Windows or MS-DOS. I saw it myself first on CP/M but it was there on VAX/VMS and I expect the Teletypes had it from 1960's.

It's not that simple. In the 1960s operating systems such as Multics existed, which even then had the idea of device independence. So the end of line sequence as far as Multics applications were concerned was a single LF, whatever the terminal type. The operating system was in charge of converting that to whatever the terminal actually needed. Multics was following the standards of the time, moreover. As the ASCII standard of the time explicitly allowed an LF could denote both a Line Feed and a Carriage Return (and indeed any padding delay characters too) in a single character if the system decided to employ single character encodings.

* H. McGregor Ross (1964-01-01). "The I.S.O. character code". DOI 10.1093/comjnl/7.3.197. The Computer Journal. Volume 7, Issue 3. pp. 197–202.

* Jerome H. Saltzer and J. F. Ossanna (1970). "Remote terminal character stream processing in Multics." DOI 10.1145/1476936.1477030. Proceedings of the AFIPS Conference 36. pp. 621-627.

* https://unix.stackexchange.com/questions/411811/

I tried to say that it was not so simple. Yes, obviously Multics had the LF line end convention. Some systems saved files internally in a record format so the line end was whatever what the software decided to print out there.

But mostly I was just reacting to the silly idea that CRLF would be right and lone LF not: Microsoft didn't come up with that idea. It was there already in 1960's and perhaps useful when you didn't want to do any line drivers for converting strings at output. But that's not really any more "right" than other conventions.

It has downsides if you're actually implementing software, but \r\n is the semantically correct way to represent a newline, because \r is Carriage Return (x=0) and \n is Line Feed (y++). In many scenarios \r is a useful primitive to have by itself, but if you want to support unix-style line endings you can't implement it, and you can't implement \n as a line feed - it has to be a newline. So in practice some expressiveness from the original character set was thrown out to save one byte per newline.

> \r\n is the semantically correct way to represent a newline, because \r is Carriage Return (x=0) and \n is Line Feed (y++)

You left out a key qualifier: CR/LF is the semantically correct way to represent a newline on a physical device that has a physical carriage that has to move back to x=0 and advance one line in the y direction in order to start a new line. What devices connected to any computer today have that property? Answer: none.

In fact, even on computers that have such devices connected, the semantic meaning of "newline" in any file the user actually edits is most likely not to actually cause a CR/LF on the device. Word processing programs for decades now have separated the in-memory and on-disk file data from the data that actually gets sent to a printer. So the file you are editing might not even have any hard "newlines" in it at all, except at paragraph breaks--and that's assuming the file format uses "newline" to mark paragraph breaks, instead of something else.

I find it funny that CRLF as a vestige of devices long gone is ridiculed, yet the same people don't bat an eye at emulating an in-band sort-of API for controlling cursor movement and display characteristics for similar devices of the past. Heck, *roff and man continue to format text by using overstriking to create underlined and bold text and rely on the terminal emulator to understand that this happened to create a particular effect on physical printers and emulate the result.

Neither world is clean, pure, and free of weirdness that's only properly understood when looking decades in the past.

Actually, the GNU tools (in particular grotty) advanced forward to 1976, and are capable of ECMA-48 control sequences that render actual italics and boldface like the source markup describes. It is just that the people who make operating systems have gone out of their way to disable this.

* http://jdebp.eu./Softwares/nosh/italics-in-manuals.html

> Answer: none.

Dot matrix printers are surprisingly common as they are still cheaper to run than the alternatives. That's at least one.

Indeed, I'm looking at my copy of "The C Program Language", second edition (ANSI C). Page 241: A text stream is a sequence of lines; each line has zero or more characters and is terminated by a \n. [\n was defined earlier as ASCII 10 and designated either as NL or LF.] An environment may need to convert a text stream to or from some other representation (such as mapping '\n' to a carriage return and linefeed)"

Reply on news.ycombinator.com