Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CRLF is obsolete and should be abolished

fossil-scm.org

Post reply on HN
Print view View original

141–150 of 273 posts

Re: CRLF is obsolete and should be abolished

#141

Post by Avamander »

forrestthewoods wrote: post #97
Avamander wrote: post #91

Earlier quoted context omitted.

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.

So what's the issue with getting rid of this debt slowly? It costs basically nothing, yet makes it cleaner for those in the future. Debts matter at a larger scale and the long run.

Re: CRLF is obsolete and should be abolished

#142

Post by chowells »

ericyd wrote: post #111

I'm not trying to be obtuse but I am actually confused how a modern machine correctly interprets CRLF based on the description in this post. If a modern machine interprets LF as a newline, and the cursor is moved to the left of the current row before the newline is issued, wouldn't that add a newline _before_ the current line, i.e. a newline before the left most character of the current line? Obviously this isn't how…

Line feed is "move the cursor down one line". It's irrelevant what is currently on the line. These are printer/terminal control instructions, not text editing instructions.

Re: CRLF is obsolete and should be abolished

#143

Post by tryauuum »

perching_aix wrote: post #17
201984 wrote: 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.

I do like concatenating files with cat, and if a file has its final line not ending in newline symbol the result is ugly.

I know it's just me but my worldview is that the world would be better if all editors had "insert final newline" behavior

Re: CRLF is obsolete and should be abolished

#145

Post by perching_aix »

tryauuum wrote: post #143
perching_aix wrote: post #17

Earlier quoted context omitted.

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.

I do like concatenating files with cat, and if a file has its final line not ending in newline symbol the result is ugly. I know it's just me but my worldview is that the world would be better if all editors had "insert final newline" behavior

My problem is that what I input (and observe!) doesn't match what's persisted. Worse still, editors lie about it to me until I close the file and reopen it. And just to really turn the knife, various programs will then throw a fit that a character that I did not input and my editor lies about not being present, is present. I hope it's appreciable why I find this frustrating.

I expect my editor to do what I say, not secretly(!) guess what I might have wanted, or will potentially want sometime in the future. Having to insert a newline while concatenating files is a chore, but a predictable annoyance. Having to hunt for mystery bytes, maybe less so.

Re: CRLF is obsolete and should be abolished

#146

Post by LegionMammal978 »

tptacek wrote: post #132
LegionMammal978 wrote: post #125

Earlier quoted context omitted.

Going down a list of top websites, these URLs respond with HTTP 200 (possibly after redirections) when sent an ordinary HTTP/1.1 GET request with 0D0A line endings, but respond with HTTP 400 when sent the exact same request with 0A line endings: https://br.pinterest.com/ https://www.pinterest.co.uk/ https://apps.apple.com/ https://support.apple.com/ https://podcasts.apple.com/ https://music.apple.com/ https://geo.itu…

You sure about this? www.pinterest.com, for instance, does not appear to care whether I 0d0a or just 0a.

My apologies, I was using a client which kept the connection alive between the 0D0A and 0A requests, which has an effect on www.pinterest.com. Rerunning the test with separate connections for 0D0A and 0A requests, www.pinterest.com and phys.org are no longer affected (I've removed the two from the list), but all other URLs are still affected.

Re: CRLF is obsolete and should be abolished

#147

Post by wongogue »

Eduard wrote: post #109

> Stop using "linefeed" as the name for the U+000a code point. stop reinventing terms. it's literally standardized with the name "LF" / "line feed" in Unicode.

He is not reinventing anything. Unicode also defines 0a as LF, NL and EOL. In modern software, 0a is used as NL anyway.

https://www.unicode.org/charts/PDF/U0000.pdf

Re: CRLF is obsolete and should be abolished

#148

Post by BlueTemplar »

ericyd wrote: post #111

I'm not trying to be obtuse but I am actually confused how a modern machine correctly interprets CRLF based on the description in this post. If a modern machine interprets LF as a newline, and the cursor is moved to the left of the current row before the newline is issued, wouldn't that add a newline _before_ the current line, i.e. a newline before the left most character of the current line? Obviously this isn't how…

If you are thinking of it being more like pressing "Home" then "Enter", it would seem that "Enter" actually works more like LFCR ?

Re: CRLF is obsolete and should be abolished

#149

Post by wongogue »

Avamander wrote: post #141
forrestthewoods wrote: post #97

Earlier quoted context omitted.

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.

So what's the issue with getting rid of this debt slowly? It costs basically nothing, yet makes it cleaner for those in the future. Debts matter at a larger scale and the long run.

They carried the debt. Why shouldn’t everyone else?

Regarding this issue…I don’t think the author is advocating for patching standards. Just consider CR as deprecated and use it only for backward compatibility.

I do it similarly. I don’t convert line endings but any new project uses LF irrespective of the OS and configured as such in the editor.

Re: CRLF is obsolete and should be abolished

#150

Post by theamk »

Spooky23 wrote: post #124
FiloSottile wrote: post #40

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…

What a weird reaction. Microsoft’s use of CRLF is an archaic pain in the ass. Taking a position that it should be deprecated isn’t radical or irresponsible — Microsoft makes gratuitous changes to things all of the time, why not this one? Hipp is probably one of the better engineering leaders out there. His point of view carries weight because of who he is, but should be evaluated on its merits. If Microsoft got rid o…

No one is talking about Microsoft and whatever it does on its platform, the parent comment is about network protocols (HTTP, SMTP and so on..).

I understand that it is tempting to blame Microsoft for \r\n proliferation, but it does not seem to be the case - the \r\n is comes from the era of teletypes and physical VT terminals. You can still see the original "NL" in action (move down only, do not go back to start of line) on any Unix system by typing "(stty raw; ls)" in a throw-away terminal.

Post reply on HN