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

161–170 of 273 posts

Re: CRLF is obsolete and should be abolished

#161

Post by bityard »

perching_aix wrote: post #7

Well, at least the title is honest. Straight up asking people to break standards out of sheer conviction is a new one for me personally, but it's definitely one of the attitudes of all time, so maybe it's just me being green. Can we ask for the typical *nix text editors to disobey the POSIX standard of a text file next, so that I don't need to use hex editing to get trailing newlines off the end of files?

Why would you want that?

All Unix text processing tools assume that every line in a text file ends in a newline. Otherwise, it's not a text file.

There's no such thing as a "trailing newline," there is only a line-terminating newline.

I've yet to hear a convincing argument why the last line should be an exception to that extremely long-standing and well understood convention.

Re: CRLF is obsolete and should be abolished

#162

Post by RedShift1 »

tptacek wrote: post #155
theamk wrote: post #151

Earlier quoted context omitted.

Wouldn't the safest thing, security-wise, to fail fast on bare 0ah? As a web server, you may not know which intermediate proxies did the request traverse before arriving to your port. Given that request smuggling is a thing, failing fast with no further parsing on any protocol deviations seems to be the most secure thing.

I mean the safest thing would be to send an RST as soon as you see a SYN for 80/tcp.

Wouldn't not replying at all be the safest?

Re: CRLF is obsolete and should be abolished

#163

Post by the_gorilla »

elcritch wrote: post #159
WesolyKubeczek wrote: post #29

> Even if an established protocol (HTTP, SMTP, CSV, FTP) technically requires CRLF as a line ending, do not comply. Send only NL. Now just go pound sand. Seriously. And you owe me 5 minutes of my life wasted on reading the whole thing. My god, I would have thought all those “simplification” ideas die off once you have 3 years of experience or more. Some people won’t learn. P. S. Guess even the most brilliant people t…

Conversely, I'd argue most brilliant people tend to have more dumb ideas than others, usually on oddly specific topics which most people would find inconsequential.

It's true. Smart people tend to have a lot of novel ideas, most of which are going to be retarded. Most people just have no ideas.

Re: CRLF is obsolete and should be abolished

#164

Post by layer8 »

Kwpolska wrote: post #120
djha-skin wrote: post #5

> Let's make CRLF one less thing that your grandchildren need to know about or worry about. The struggle is real, the problem is real. Parents, teach your kids to use .gitattribute files[1]. While you're at it, teach them to hate byte order marks[2]. 1: https://stackoverflow.com/questions/73086622/is-a-gitattribu... 2: https://blog.djhaskin.com/blog/byte-order-marks-must-diemd/

Nope. Git should not mess with line endings, the remote repository not matching the code in your local clone can bite you when you least expect it. On Windows, one should disable the autocrlf misfeature (git config --global core.autocrlf false) and configure their text editor to default to LF.

This is impractical in many situations, because tools that process build-source files (for example XML files that control the build, or generated source files) inherently generate CRLF on Windows. These are many, many, many tools, not just one’s text editor.

The correct solution is to use .gitattributes.

Re: CRLF is obsolete and should be abolished

#165

Post by bityard »

perching_aix wrote: post #145
tryauuum wrote: post #143

Earlier quoted context omitted.

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 s…

I have been using and programming Unix systems for almost 30 years and have not run into anything like what you are describing.

What Unix program "throws a fit" when encountering a perfectly normal newline in the last line in a file?

Re: CRLF is obsolete and should be abolished

#166

Post by cowsandmilk »

numpad0 wrote: post #115
sunk1st wrote: post #81

> Nobody ever wants to be in the middle of a line, then move down to the next line and continue writing in the next column from where you left off. No real-world program ever wants to do that. Is this true?

isn't CR without LF how CLI progress bars work?

He says there are good usages of CR, he only argues for getting rid of LF.

Re: CRLF is obsolete and should be abolished

#168

Post by perching_aix »

sophacles wrote: post #129
perching_aix wrote: post #60

Earlier quoted context omitted.

When an implementation is noncomformant to a standard in question.

I've implemented a lot of protocols. Most implementations I've come across for most protocols not strictly standards conformant, for many reasons. Big ones being: * The standards are often not detailed enough, or contain enough loose verbage that there are many ways to understand how to implement some part, yet those ways are not interoperable. * Many protocols allow vendor specifications in such a way that 2 impleme…

I'm aware of these factors, wasn't trying to suggest that the practice doesn't differ from the theory. What I was more going for was to highlight that the goal should be to primarily try and have these eventually converge, preferably sooner than later, not trying to strongarm the practice side and wait for the standards body in question to wake up one day and decide to amend the standard. That might give the impression of suddenness, but the core issue remains unsolved that way.

Usually when there's a high disparity between the "de jure" and the "de facto", it's due to a discrepancy in the interests and the leverage, resulting in a breakdown in communication and cooperation. Laying into either then is a bandaid attempt, not a solution. It's how either standard sprawl starts, or how standards bodies lose relevance.

Re: CRLF is obsolete and should be abolished

#169

Post by ripe »

Ha, ha, ha! I love it. I believe the author is serious, and I think he's on to something.

OP clearly says that most things in fact don't break if you just don't comply with the CRLF requirement in the standard and send only LF. (He calls LF "newline". OK, fine, his reasoning seems legit.) He is not advocating changing the language of the standard.

To all those people complaining that this is a minor matter and the wrong hill to die on, I say this: most programmers today are blindly depending on third-party libraries that are full of these kinds of workarounds for ancient, weird vestigial crud, so they might think this is an inconsequential thing. But if you're from the school of pure, simple code like the SQLite/Fossil/TCL developers, then you're writing the whole stack from scratch, and these things become very, very important.

Let me ask you instead: why do you care if somebody doesn't comply with the standard? The author's suggestion doesn't affect you in any way, since you'll just be using some third-party library and won't even know that anything is different.

Oh bUT thE sTandArDs.

Re: CRLF is obsolete and should be abolished

#170

Post by layer8 »

BlueTemplar wrote: post #148
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 ?

Unless your editor is in auto-indent mode. ;)
Post reply on HN