←back to thread

352 points dgl | 1 comments | | HN request time: 0.413s | source
Show context
mrheosuper ◴[] No.44505697[source]
it's 2025 and we still can't decide to use /r, /n or /r/n.
replies(3): >>44508327 #>>44508496 #>>44512444 #
layer8 ◴[] No.44508496[source]
Lone CR died with classic Mac OS over 20 years ago, I think we can ignore that. Lone LF is arguably a Unix-ism, everything else is/was using CRLF. Except that Unix text files are becoming ubiquitous, while existing protocols and formats, as well as Windows conventions, are stuck with CRLF. There’s really no good way out.
replies(1): >>44508917 #
pjc50 ◴[] No.44508917[source]
I'm on team "Windows should just accept and change to write and read CR and '/'. beginning the decades long transition process for those". Most of the APIs accept '/', and most of the software accepts CR-only.

I think even Microsoft have noticed this, which is why WSL exists to provide an island of Linux-flavored open source tooling inside a Windows environment.

replies(1): >>44509246 #
1. layer8 ◴[] No.44509246[source]
I think you mean LF, not CR. The problem with changing the behavior with regard to CRLF is exactly that it would introduce vulnerabilities like the present one here, because some software would still apply the old behavior while others apply the new one. Stuff like https://portswigger.net/web-security/request-smuggling/advan....

Directory separators are another can of worms. A lot of functionality in Windows is driven by command-line invocations taking slash-prefixed options, where it’s crucial that they are syntactically distinct from file system paths. I don’t think a transition is possible without an unacceptable amount of compatibility breakage.