Hacker News Reader

Comment by forrestthewoods | Hacker News Reader

I have absolutely zero sympathy for any tool that is incapable of handling \r\n and only works with \n. Literally absolutely no sympathy.

All software accumulates warts over time. Linux is overflowing with horrible warts and tech debt. As is any software that has successfully served customers for decades.

But multiple line endings are quite possibly the easiest most trivial thing to support and there is absolutely no negative cost of any kind in doing so. Linux ecosystem chooses to be stubborn and provide a strictly worse user experience out of pure spite and for zero user benefit. It’s very irritating.

View on HN

> But line endings are quite possibly the easiest most trivial thing to support and there is absolutely no negative cost of any kind in doing so. Linux ecosystem chooses to be stubborn and provide a strictly worse user experience out of pure spite and for zero user benefit. It’s very irritating.

The Linux ecosystem handles it fine (by using a single standard). Windows doesn't. That's its problem.

> The Windows ecosystem handles it fine (by using a single standard). Linux doesn't. That's its problem.

It's always funny to see how the fanbois treat their way as the one and only 'True Way'.

I didn't say it was the one and only True Way. My intended meaning - which I admit I may have poorly conveyed - is that tools from the unix ecosystem are intended to work on unix conventions, and do, and that works. Windows has different standards, which is also fine, but it follows that you shouldn't expect unix tools to follow Windows standards even if you make them run on Windows. This is like getting Windows software to run under WINE and then complaining that it doesn't use /n newlines and that it should change to accommodate Linux (or whatever). No, a Windows program will follow Windows standards even when made to run on a unix-like. And in the same way, unix-family software is going to follow unix standards even on Windows.

Your entire framing is wrong imho.

Multi-platform is very easy and a solved problem if you try juuuust a tiny amount.

For example the Rust stdlib iterator for lines() handles both conventions. It just works. Very easy.

I live in a cross-platform world. Line endings in text files should not be a breaking problem because some CLI tool refuses to support both. That’s just plain bad software engineering.

I expect Unix tools that process text files to be capable of supporting text files that have different conventions. This is very easy. Refer to previous comments on stubbornness out of spite.

Even Python has str.splitlines, which accepts a range of line separators (not just LF and CRLF), and the same when iterating over a file handle (which iterates over lines).

You're right, this is a complete nonissue.

I think the point is that line endings are a really, really stupid hill for either Linux or Windows to die on. The day when any programs should have cared about line endings came and went decades ago.

UNIX and Windows aren't the only OSes on the planet, even though UNIX folks tend to assume that.

Heck many mistake UNIX with GNU/Linux even, and then complain when given a UNIX that isn't a Linux distro.

Comments like this really make me wish HN allowed you to block users. Alas.

If you have something to say, say it. This is barely even an ad hominem.

Complete and utter nonsense. Every Windows tool I remember using has handled LF-only endings perfectly fine, meanwhile Linux tools regularly fail to handle CRLF endings.

> Every Windows tool I remember using has handled LF-only endings perfectly fine

cough notepad cough

Reply on news.ycombinator.com