4 ms·

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

by aktau 9y ago

ptaipale 9y ago
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.
- JdeBP 9y ago
  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/ https://unix.stackexchange.com/questions/411811/
  - ptaipale 9y ago
    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.
kevingadd 9y ago
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.
- pdonis 9y ago
  > \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.
  - ygra 9y ago
    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.
    - 9y ago

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

by aktau 9y ago

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.

JdeBP 9y ago
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/ https://unix.stackexchange.com/questions/411811/
- ptaipale 9y ago
  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.

kevingadd 9y ago

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.

pdonis 9y ago
> \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.
- ygra 9y ago
  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.
  - 9y ago