Developer tools · Text comparison
Why Windows and Unix Disagree on Line Endings: The CR, LF and CRLF Story
· Background
text-diff line-endings software-history
Traces line endings from typewriters and teletypes to modern operating systems and explains why two conventions still coexist in every cross-platform project.
One invisible character, decades of friction — opens with the persistent cross-platform annoyance
Line endings are invisible in ordinary editors yet can matter to files and protocols. In ToolAcre, however, CR, LF and CRLF are normalized before line comparison. A pair differing only in those separators produces the same line array and an identical result.
That behavior resolves the practical question for this route while limiting what it can diagnose. The comparison cannot prove which newline bytes the original files contained after the text reaches its editors. A byte-aware tool is required for preservation or protocol checks.
Carriage return and line feed on a typewriter — explains the two physical actions the characters originally described
The terms carriage return and line feed have physical and historical meanings, but the repository contains no typewriter source. Repeating a mechanical origin story from memory would violate the evidence contract even if the account sounded familiar.
This article therefore treats CR as the ` ` code unit and LF as ` ` only where the implementation uses them. Historical explanation should be added later from primary standards or archives rather than borrowed from an outline that is explicitly not a source.
Typewriter meanings are historical claims requiring external sources
Likewise, the source files do not document teletype conventions or early operating-system decisions. They reveal only a compatibility choice in current JavaScript: replace every CRLF or lone CR with LF before splitting.
That transformation accepts pasted text produced under several conventions without filling the output with ending-only changes. It is an implementation decision visible in one regular expression and pinned by tests for all three forms.
Teletype and operating-system lineage is outside repository evidence
It is common to associate Unix with LF, Windows with CRLF and older systems with lone CR, but the current repository cannot serve as historical proof of those adoptions. The safe claim is operational: all three inputs become LF inside `splitLines`.
A terminal LF does not create a final empty row, while blank lines in the middle remain. This distinction means logical content is retained even though physical separator differences are erased. The comparison is line-oriented, not byte-preserving.
The code proves three conventions normalize; it does not prove why systems adopted them
Some network and message protocols specify exact line terminators, but their requirements must come from their specifications. ToolAcre’s normalization makes it unsuitable for proving conformance to such a wire format because the original separator evidence is intentionally removed.
Use a hex viewer or protocol validator before parsing when exact CRLF sequences matter. A clean Text diff result can confirm matching logical lines and simultaneously conceal a transport-level defect. Both observations can be true because the tools answer different questions.
Protocol requirements need their own specifications and are omitted here
Compare `alpha beta`, `alpha beta` and `alpha beta` in pairs. Each produces two lines, alpha and beta, and no additions or removals. Ignore whitespace does not cause this equality; normalization has already happened during splitting.
Add trailing spaces to one beta row and ordinary mode will now report a difference. Enable Ignore whitespace and it may disappear. The sequence separates newline handling from line-key whitespace handling and prevents crediting the wrong option.
Worked example: all three ending forms compare as equal before whitespace options
This route does not configure editors, rewrite files, set Git attributes or bulk-convert endings. It also does not expose the original separator in result rows. Pasted strings enter a comparison pipeline, not a newline migration utility.
Historical causation and protocol standards are omitted pending sources. That restraint leaves a smaller but exact article: what three conventions do in this implementation, which blank lines remain and why equality here does not establish byte identity.
Takeaway: know which convention your text carries — summarises the history and how ToolAcre's Text comparison helps confirm whether a difference is only line endings
Know which evidence survived the tool. After normalization, ToolAcre can compare logical line content across common separators. It cannot tell you which convention either source used or whether a downstream consumer requires one exact byte sequence.
Use the browser diff for human review and a byte-level check for repository or protocol enforcement. A tool is reliable when its transformations are explicit; reviewers remain responsible for selecting one that preserves the property they need to verify.