3 ms·
Interesting that you find \r\n to be "right" and the others "screwed up". I'm curious about the reasons for that. The biggest problem is that each OS went its
by Stratoscope 9y ago
Interesting that you find \r\n to be "right" and the others "screwed up". I'm curious about the reasons for that.
The biggest problem is that each OS went its own way (Mac started with \r but of course uses \n now). If they all had the same line ending all along, whatever it was, no one would think much about it.
\r\n has the obvious disadvantage of being twice the size, along with making it possible to land in the middle of a line ending instead of before or after one.
Of course one advantage would be if you're controlling physical equipment where carriage return and line feed are independent of each other. I learned to program in 1968 on a Teletype ASR33 where CR and LF were literal commands to return the carriage to column 1 and advance the paper. You had to use both because they did two different things. Or on occasion you might use CR by itself to overprint a line. LF by itself was pretty rare, but would do what you expect if you used it: advance the paper without moving the print carriage.
CR LF was fine if you were typing interactively - in fact you just had to hit the CR key and the remote system would provide the LF. But usually we would punch our programs on paper tape, dial in, run the tape through and get the printout, and hang up right away. At $30/hour in 1968 dollars, this saved a lot of money. And of course you would run your tape through locally to print out and proofread your program before testing it online.
To be able to print a tape locally, you needed both CR and LF, but even that wasn't quite adequate. You really wanted to allow a little extra time for the machinery to settle, so the standard line ending we punched on a tape was CR LF RUBOUT.
RUBOUT was a character that punched out all the holes in a row of the paper tape. It was ignored by convention, so you could erase a typing error when punching a tape by pushing the backspace button on the tape punch and hitting the RUBOUT key.
Because it was ignored, RUBOUT was also useful as a "delay" character in the newline sequence. So I guess I'll never get over the feeling that the One True Line Ending is: \r\n\x7F
(Nah, I'm happy with \n, but it makes a good story.)
- walshemj 9y agoCould have been something that came from DEC as the original NT was influenced by VAX systems (which often had LA120's as consoles) I seem to recall.
- diffuse_l 9y agoNot likely, as NT got this behaviour from DOS, And DOS probably got this from CP/M.
- spc476 9y agoAnd CP/M was influenced by RT-11, another DEC operating system, bringing us full circle.
- pedasmith 9y agoCertainly not from DEC. DEC had a powerful "RMS" (record management system) later between a program and the disk. That later would take files in a balloon formats and convert them as needed. For example, you could define that your file was fixed length records (like the old punch cards); at that point each line doesn't have a line separator at all; the \n or\r is not stored on disk. But when you read a line using the C routines, one will be added.
- walshemj 9y agoWe are talking about the usage or CR/LF for terminal devices the LA120 and so on not some internal binary file standard. I am not sure what C or RMS has to do with this
- pedasmith 9y agoBecause we're talking about how end-of-line is marked in a file, not in a terminal. DOS specifies the end-of-line in a file as CR/LF.
- JdeBP 9y agoNUL was also a common delay character, and one can find some of the delay mechanisms, enshrined in the POSIX standard as part of the General Terminal Interface, in Linux even today. (They are largely gone from OpenBSD and FreeBSD.) * http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap11.html#tag_11_02_03 http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_...