Skip to main content
24 events
when toggle format what by license comment
Aug 11 at 10:05 vote accept Simon Kissane
Jul 30 at 23:18 comment added Simon Kissane @SergeBallesta: the standard explanation for that is that using CR as newline on output makes overprinting harder on hardcopy terminals and impact printers. You can still do it using backspace, but using CR to go straight to the start of the line and then printing a modified version was easier. Whereas, most early 8-bit micros had video displays where that wasn’t as big of an issue; early CP/M systems were used with hardcopy terminals, and notably CP/M (and its spiritual descendants including DOS/Windows/OS/2) stuck with the full CR+LF
Jul 30 at 20:08 comment added Serge Ballesta The most usual terminals used to label the key that was used to terminate a line Carriage Return, by analogy to the older manual typing machines where you manually used a small lever to bring the carriage holding the paper sheet back to its initial position. So using the CR character to terminate a line should have been a natural solution. IMHO the good question is instead why on earth Multics engineers decided to use a different character (the Line Feed one) to register an end of line...
Jul 30 at 5:27 comment added chux @DogBoy37 Concerning an old manual typewriter: I recall having the ability to perform 1) a line-feed/carriage return together (the line feed physically happened first), 2) A line feed only (usually followed by a regular line-feed/carriage return to skip multiple lines), 3) a carriage return only (to over print the line). Although CR/LF was what a typist usually wanted, I could see the desire for a single code in computers to end-a-line in the byte cost a $ days.
Jul 29 at 21:10 comment added dan04 One of the "various other conventions" for the end-of-line character was ATASCII's \x9B. I don't know why they chose that particular code.
Jul 29 at 15:15 answer added Mike James timeline score: -2
Jul 29 at 2:44 comment added dave PDP-11 Unix (1st ed) used newline as line terminator. It by default expected terminals to treat 012 as newline, being biased to model 37 teletypes which apparently had that as an option. See the special files man section, files tty0 to tty5. However, newline could be simulated on output by CR/LF, and CR on input could be converted to 012. So is CR a line terminator?
Jul 28 at 23:28 history edited Simon Kissane CC BY-SA 4.0
link to related question about LF+CR convention on Acorn BBC/RiscOS
Jul 28 at 16:33 answer added Raffzahn timeline score: 19
Jul 28 at 15:16 comment added dave My overall point is, you are trying to establish "the first" to store just CR, as if there's a line of succession, for what I see as a local choice, organically made. Even if there is a first, chronologically speaking, it does not follow that others "copied" the convention, whatever the convention is (CR, NL, CR-LF, count).
Jul 28 at 15:10 comment added dave It's not just 'mainframes' and 'ebcdic'. Counted records, no stored terminators, were standard on many DEC PDP-11 systems and on VMS. All minicomputers with ASCII character set.
Jul 28 at 14:22 comment added DogBoy37 Acknowledge that it goes all the way back to the typewriter (Manual). Carriage Return and Line Feed were both accomplished by the handle. First the CR and the LF. The LF when the carriage hit the end.
Jul 28 at 10:34 comment added Raffzahn @hippietrail If EBCDIC is meant to mean/360ish mainframes, line length in next to all handling was done by length termination, either fixed (think 80 char punch cards or tape blocks),or variable with a preceding length (usually halfwords). the only somewhat common use case for a line terminator was teletypes and non formatted terminal output. For such it was neither CR (x'0D') not LF (x'25') but 'logical new line' NL (x'15').
Jul 28 at 10:31 comment added tofro Isn't the choice of a line-ending character a relatively arbitrary one? (Except for the Sinclair ZX81, where it had to be $76, for reasons - and nobody cared). Especially for home computers, that were unlikely to ever come in contact with professional IT or TTYs, the choice was obviously 50:50 between LF and CR, the obvious candidates. Sinclair did, BTW, unlike the ZX Spectrum, use LF on the QL, because that targeted the "professional market".
Jul 28 at 6:44 history became hot network question
Jul 28 at 6:43 history edited user3840170 CC BY-SA 4.0
deleted 1 character in body; edited title
Jul 28 at 4:01 comment added Simon Kissane I knew all that stuff about mainframes, EBCDIC, etc, but I left it out of the question for sake of brevity. However, since people are bringing it up I added mention of it. Still, want to focus here on the bare CR convention, not what mainframes/etc did
Jul 28 at 4:00 history edited Simon Kissane CC BY-SA 4.0
added 560 characters in body
Jul 28 at 3:28 comment added hippietrail What did EBCDIC systems use?
Jul 28 at 2:04 comment added dave The Multics line terminator was called 'newline' and was represented by 012. It specifically moved the print position to the first column of the next line. On devices that did not have a 'newline' it could be sent as carriage return, line feed. But internally it was a 'newline' character. The point may be obscure if you have only used systems where the internal code and all device codes are identical, but this has not always been true. Newline is a natural choice if you have newline-capable devices; it occurred organically on more than one system.
Jul 28 at 1:52 comment added dave You missed one major approach to line terminators, and that is to not actually have them in file systems. You can see this approach, for example, in systems that began with card input. Why invent a 'line terminator' character you don't need?
Jul 28 at 0:33 comment added Raffzahn For 8 bit systems it was not really about copying a first but practical application - and part of the common theme of reinventing the wheel. Unix and others moved from physical control (CR+LF) to logical (LF) by employing device drivers to handle any mapping. Micros (re)started development without device drivers, without a driver translating a CR send by ENTER but giving it right to application. Terminals (and printers) could be configured to treat CR (or LF) as CR+LF, making use of CR the most simple way in and out. Once early micros had established this, the rest was copying/following.
Jul 28 at 0:05 answer added Leo B. timeline score: 14
Jul 27 at 22:43 history asked Simon Kissane CC BY-SA 4.0