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?
The balance here, of course, being backwards compatability. I'd sooner kill EBCDIC, bad ASCII and Code Pages than worry about CRLF if we didn't have to care about ancient systems.
Programming languages still retain C's operator precedence hierarchy even though it was itself meant to be a backwards compatible compromise and leads to errors around logical operator expressions.
Anyways, this article is about actively breaking systems like some kind of protocol terrorist in order to achieve an outcome at any cost, if it was merely along the lines of "CRLF considered harmful in new protocols" I'd have nothing to say.
> You didn't limit your general admiration of standards to CRLF, so no, not only that.
So your position, then, is that all standards include "needless complexity?" What argument are you actually trying to make here?
> That's simply false, he isn't
Yea.. that's why the word "like" is present, it implies a near association, not a direct accusation.
> Almost all implementations of these protocols will accept a bare NL as an end-of-line mark, even if it is technically incorrect.
So, right back to my original point, then, standards prevent people from having to debug dumb issues that could have been avoided. This advice is basically "go ahead, create dumb issues, see if I care."
I may have flippantly labeled that as "protocol terrorism" but I don't think it's pure hyperbole either.
> What argument are you actually trying to make here?
That you're mistaken in your one-sided generalization of the benefits of standards.
> So your position, then, is that all standards include "needless complexity?"
No, that's just another extreme you've made up.
> Yea.. that's why the word "like" is present, it implies a near association, not a direct accusation.
Your mistake is before "like", you can't be "about actively breaking systems" when you explicitly say that no systems will be broken
> "see if I care."
That this is false is also easy to see - the author reverted a change after he realized it breaks something ancient, so clearly he does care.
> standards prevent people from having to debug dumb issues that could have been avoided.
Not to circle the conversaion back to my original response to your point: why do you think "Almost all implementations" break the standard and "accept a bare NL"? Could it be that such unintuitive limitations don't prevent anything, and people still have to debug "dumb issues" because common expectations are more powerful?
> Almost all implementations of these protocols will accept a bare NL as an end-of-line mark, even if it is technically incorrect.
See https://news.ycombinator.com/item?id=41832555 as far as HTTP/1.1 goes, it's definitely common but far from universal. The big problem with "it's 100% safe to make this change, since it doesn't break anything I know about" is that there are always a lot of things you don't know about, not all of which can be boiled down to being negligible weirdos.
Might be just my personal impression, but I'm pretty sure Chrome is extremely notorious for abusing its market leader position, including in this way. So gonna have to disagree there, from my view people do mind Chrome and its implementation particularities quite a lot.
> There's no such thing as a "trailing newline," there is only a line-terminating newline.
Is "line-terminating newline" a controlled / established term I'm unfamiliar with or am I right to hold deep contempt against you?
Because "trailing newline", contrary to what you claim, is 100% established terminology (in programming anyways), so I'd most definitely consider it "existing", and I find it actively puzzling that someone wouldn't.
A trailing newline to me is "\n\n" at the end of a file, i.e. a superfluous empty line. That doesn't seem to be what the root comment is referring to, though?
In my head, a trailing newline is a newline, at the end, on its own, a blank line after the last line in a file… that's a file ending in \n\n (or more).
It hadn't even occurred to me until today that anything else could be meant :o
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.
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.
"Unix programs" I haven't ran into throwing a fit per se. That's why I didn't write that.
What I ran into issues with was contemporary software that's shipped to Linux, such as Neo4j, which expects its license files to have no newline at the end of the file, and will actively refuse to start otherwise.
I have a feeling I'll now experience the "well that's that software's problem then" part of this debate. Just like how software not being able to handle CRLF / CR-only / LF-only, is always the problem - instead of text files being a joke, and platforms assuming things about them being the problem.
It makes writing parsers more complicated in certain cases because you can't tell without lookahead if a newline character should be treated as a newline or an eof.
I won't mention telnet because you don't use it, but in CSV and similar data it is quite a trouble to normalize the data. So instead of 2 possibilities now we 3 to detect.
I don't get the CSV part. You can emit a new row after a line ending and on EOF with non-empty buffer. What's the tricky part or third option here? The crlf is never a part of the data.
Absolutely correct: You never had issues. Other people have built other software that does not use modern CSV libraries. They work just fine today and don't need to update, wouldn't even be possible for most cases in either case.
Please do consider that many software products will not change and they will still be actively used on production environments that you will never have interest about.
Well, GP proposed removing the idea of trailing newlines from standard *nix tools entirely, so I think it's fair to ask what shop is going to update their RHEL deployment to upgrade to a version of `cat` or `sed` that doesn't have trailing newlines but can't spend 5 minutes to handle a newline properly in their CSV parser? That doesn't make a lot of sense.
And it was pretty clear from the context of norir's comment that they were not talking about legacy software, they were talking about writing new projects/file formats that used newlines as a separator. Just because you want to shoehorn your legacy projects into this discussion doesn't mean that they fit.
Yeah, I have no idea what the author is smoking. Deliberately breaking standards is simply not an acceptable solution to the problem, even if it were a serious problem (it's not).
If there truly is a problem with existing protocols, propose and properly design new one that can replace it. Then if it is technically superior solution it should win in long run.
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?