←back to thread

422 points km | 2 comments | | HN request time: 0.522s | source
Show context
moomin ◴[] 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. eqvinox ◴[] No.41835527[source]
Counter-counterpoint: using 2 bytes to signal one relevant operation creates ambiguity out of thin air. If all you care about is "where does the line end?", having CRLF as a line ending creates edge cases for "there is only CR" and "there is only LF". Are those line endings or not? How do you deal with them? And what's LFCR?

Personally speaking, I've always written my parsers to be permissive and accept either CR¹, LF, or CRLF as line endings. And it always meant keeping a little extra boolean for "previous byte was CR" to ignore the LF to not turn CRLF into 2 line endings.

¹ CR-only was used on some ancient (m68k era?) Macintosh computers I believe.

P.S.: LFCR is 2 line endings in my parsers :D

replies(1): >>41838126 #
2. sebazzz ◴[] No.41838126[source]
Didn’t some version of an Apple operating system have CR as a line ending?