12 ms·

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 o

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.

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.