Live data from Hacker News

CRLF is obsolete and should be abolished

fossil-scm.org

91–100 of 273 posts

Re: CRLF is obsolete and should be abolished

#91

I could not possibly disagree with this more strongly or violently. In short - shutup and deal with it. Is it an extremely mild and barely inconvenient nuisance to deal with different or mixed line endings? Yes. Is this actually a hard or difficult problem? No. Stop trying to force everyone to break their backs so your life is inconsequentially easier. Deal with it and move on.

Why do we _have to_ keep bringing this legacy baggage with us for the next decades though?

Allowing CRFL-less operation intentionally, especially in new implementations. Abusing protocol tolerance is (just a bit) to switch current ones. Should allow relatively gradual progress towards Less Legacy:tm: with basically no cost.

Not every change is "breaking your back" especially if you should be updating your systems anyways to implement other, larger and more important changes.

Re: CRLF is obsolete and should be abolished

#92
Does anyone besides poorly designed Unix tools and Git actually get confused by any of this? I configure my editor to just use LF on whatever OS to appease Linux and configure Git to never mess with them. And in dealing with serial protocols, it's never an issue.

Re: CRLF is obsolete and should be abolished

#93
post #16

Earlier quoted context omitted.

What's wrong with trailing newlines?

Other than select software being pissy about it, not much. Just like how there's nothing wrong with CRLF, except for select software being pissy about that too.

Yep. Select software being Unix command line tools.

Re: CRLF is obsolete and should be abolished

#94

Earlier quoted context omitted.

>> I'm hoping this is satire. Why intentionally introduce potential bugs for the sake of making a point? It's not satire and it's not just trying to make a point. It's trying to make things simpler. As he says, a lot of software will accept input without the CR already, even if it's supposed to be there. But we should change the standard over time so people in 2050 can stop writing code that's more complicated (by ne…

Yes. We all know how to do this. You know that API version thingy. I agree to drop the carriage return when not needed but do it in future protocols. Obviously IPv6 shows you need to be patient. Your great grandkids may see a useless carriage return! Windows doesn't help here.

Versioning provides people with capability for change management, but won't perform it on their behalf. Who knew.

Re: CRLF is obsolete and should be abolished

#95
post #41

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.

I have always felt that somehow Linux and proponents of it default to every decision it made being right and everything else, namely Windows, being wrong. I honestly feel Linux is orders of magnitude more complex. It is much easier, in my experience to make software just work on Windows. (This is not to say Windows doesn't have bad decisions. It has many. All the major OSs are terrible.)

Re: CRLF is obsolete and should be abolished

#97

I could not possibly disagree with this more strongly or violently. In short - shutup and deal with it. Is it an extremely mild and barely inconvenient nuisance to deal with different or mixed line endings? Yes. Is this actually a hard or difficult problem? No. Stop trying to force everyone to break their backs so your life is inconsequentially easier. Deal with it and move on.

Why do we _have to_ keep bringing this legacy baggage with us for the next decades though? Allowing CRFL-less operation intentionally, especially in new implementations. Abusing protocol tolerance is (just a bit) to switch current ones. Should allow relatively gradual progress towards Less Legacy:tm: with basically no cost. Not every change is "breaking your back" especially if you should be updating your systems any…

Because it’s literally fine and a non-issue. Only whiny Linux babies cry about it. It’s trivial for tools to support. Trivial. Like this is easiest, least harmful baggage in the history tech debt baggage.

There will always be tech debt. Always and forever. Burn cycles on one that matters.

Re: CRLF is obsolete and should be abolished

#99
post #45

Earlier quoted context omitted.

Exactly. Please DO NOT mess with protocols, especially legacy critical protocols based on in-band signaling. HTTP/1.1 was regrettably but irreversibly designed with security-critical parser alignment requirements. If two implementations disagree on whether `A:B\nC:D` contains a value for C, you can build a request smuggling gadget, leading to significant attacks. We live in a post-Postel world, only ever generate and…

This would be more persuasive if HTTP servers didn't already widely accept bare 0ah line termination. What's the first major public web site you can find that doesn't?

As the parent mentioned, it's security critical that every HTTP parser in the world - including every middleware, proxy, firewall, WAF - parses the headers in the same way. If you write a HTTP parser for a server application it's imperative you don't introduce random inconsistences with the standard (I can't believe I have to write this).

On the other hand, as a client, it's OK to send malformed requests, as long as you're prepared that they may fail. But it's a weird flex, legacy protocols have many warts, why die on this particular hill.

Re: CRLF is obsolete and should be abolished

#100

This article seems like it was written to troll people into a flame war. There is no such character as NL, and the article does not at all address that fact that the "ENTER" key on every keyboard sends a CR and not a LF. Things work fine the way they are.

U+0085 is sometimes called NL (it is the standard in EBCDIC), but more often NEL in the ASCII world.
Post reply on HN