←back to thread

CRLF is obsolete and should be abolished

(fossil-scm.org)
422 points km | 2 comments | 13 Oct 24 19:16 UTC | HN request time: 0.428s | source
Show context
moomin ◴[13 Oct 24 20:39 UTC] No.41831394[source]▶
Counterpoint: Unix deciding on a non-standard line ending was always a mistake. It has produced decades of random incompatibility for no particular benefit. CRLF isn’t a convention: it’s two different pieces of the base terminal API. You have no idea how many programs rely on CR and LF working correctly.
replies(5): >>41831757 #>>41832003 #>>41832081 #>>41835025 #>>41835527 #
1. matheusmoreira ◴[13 Oct 24 21:25 UTC] No.41831757[source]▶
Yeah. It's weird how Unix picked LF given its love of terminals. CRLF is the semantically correct line ending considering terminal semantics. It's present in the terminal subsystem to this day, people just don't notice because they have OPOST output post processing enabled which automatically converts LF into CRLF.
replies(1): >>41835552 #
2. eqvinox ◴[14 Oct 24 08:49 UTC] No.41835552[source]▶
I'd argue (but have no historical context) that it's a distinction between storage format and presentation interface, and IMHO that makes a lot of sense. A terminal has other operations too, backspaces and deletes being the most basic. Which coincidentally are one hell of a mess across different terminal types between ^H / 0x08 and DEL / 0x7f as well…

(And these distinctions predate UNIX — if I were confronted with an inconsistent mess I'd go for simplicity too, and a 2-byte newline is definitely not simple just by merit of being 2 bytes. I personally wouldn't have cared whether it was CR or LF, but would have cared to make it a single byte.)