Why line endings differ between systems

1963ASCII, as standardised

The standard defines a carriage return and a line feed as two separate control characters, because on the machines it was written for they were two separate physical actions.

Carriage return moved the print head back to the left margin. Line feed advanced the paper by one line. Doing one without the other was useful: returning without feeding overprinted a line, feeding without returning produced a staircase.

1960sTeleprinter mechanics

The machines were slow enough that the order mattered and the timing mattered. Moving the head across the full width took longer than transmitting the next character, so operators padded the sequence with characters that did nothing while the mechanism caught up.

Every part of that is about a physical object moving.

1970s onwardsThree descendants

When the paper disappeared, the pair had to be reduced to a convention, and three groups reduced it differently.

One kept the line feed alone and treated the return as the display's problem. Another kept both characters, preserving the teleprinter sequence. A third kept the return alone. All three are internally consistent and none is a mistake.

1960sWhat the padding characters were for

Worth making concrete, because it explains an oddity still visible in old files. After a carriage return, the print head took longer to cross the platen than the line was to arrive, and any character sent during the crossing would be printed somewhere in the middle of the sweep or lost.

The fix was to send characters that do nothing, sized to the delay. Terminal settings for padding survived in system configuration for decades after the last machine that needed them, and text files occasionally still carry them.

present dayWhat the disagreement costs now

The practical bill arrives in three places. Text files moved between systems show either a stray character at the end of each line or no line breaks at all. Version control has to decide whether a change of convention is a change of content, and every mixed team eventually spends an afternoon on the answer. And string comparison silently fails when one side carries the extra character.

None of it is difficult. All of it is the residue of two mechanical actions that had to be performed in the right order on a machine that no reader of this has used.

present dayHow the convention is detected

No file records which convention it uses. Tools guess, by looking at what the first few line breaks contain, and a file that mixes both defeats the guess.

Mixed files are common, because they are produced whenever two tools with different assumptions edit the same file, which happens silently and often. The resulting damage tends to appear far from its cause: a script that will not run, a configuration line that is ignored, a comparison that reports a difference nobody can see.

1980s onwardsThe one place it is decided for you

Protocol specifications settled the question in their own domain by requiring both characters, and that requirement is strict: an implementation that emits only one is out of specification even though most receivers accept it.

The result is a stable arrangement nobody would design. Files on the same machine disagree, and the wire between machines does not, because the wire had a committee and the files had habits.

present dayWhat to do about it in practice

The arrangement that stops the recurring afternoon is to declare the convention per file type in the repository, normalise on the way in rather than on the way out, and leave the working copy alone.

Declaring it matters more than which one is declared. Almost all of the cost here comes from two tools disagreeing silently, and almost none of it from either convention being worse than the other.

1980s onwardsWhy nobody fixed it

There were opportunities. Each new system, each new protocol, each standard revision could have settled on one form and converted at the edges.

None did, for the reason that runs through this whole part: the cost of changing falls on whoever changes, and the cost of not changing is spread across everybody, forever, in small amounts. Two characters instead of one is a tiny price per line, and it is paid by people who were not in the room.

What a line break is not

One clarification prevents most of the confusion. Neither character means end of line in the abstract; both are instructions to a machine about what to do next. Files that hold text as a sequence of records with their own lengths, which several systems used, have no line break characters at all.

Treating a line break as a character in the text rather than as a separator between records is itself an inherited choice, and it is the reason a trailing break at the end of a file is ambiguous enough to have its own long-running argument.

present dayWhere the pair survives

The internet protocols specify both characters. Mail and the hypertext transfer protocol define their line breaks that way, so software that has never touched a teleprinter still emits a sequence designed for one.

The version control disagreement that consumes an afternoon in most mixed teams is the same split, arriving by a different route.

What we cannot verify

Why each system chose as it did is documented unevenly. The standard's definitions and the mechanics are firm. The reasoning behind one particular operating system's choice is generally reported through later recollection rather than through a document from the time, and accounts differ on how deliberate it was.