3 ms·
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 accumula
by forrestthewoods 5mo ago
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.
- yjftsjthsd-h 5mo ago> 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.
- justsomehnguy 5mo ago> 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'.
- yjftsjthsd-h 5mo agoI 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.
- forrestthewoods 5mo agoYour 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.
- maleldil 5mo agoEven 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.
- CamperBob2 5mo agoI 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.
- pjmlp 5mo agoUNIX 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.
- forrestthewoods 5mo agoComments like this really make me wish HN allowed you to block users. Alas.
- yjftsjthsd-h 5mo agoIf you have something to say, say it. This is barely even an ad hominem.
- cindyllm 5mo ago[dead]
- Measter 5mo agoComplete 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.
- hulitu 4mo ago> Every Windows tool I remember using has handled LF-only endings perfectly fine cough notepad cough