4 ms·

it's 2025 and we still can't decide to use /r, /n or /r/n.

account42 1y ago
Of course we can, it's just that some people decide wrong.
layer8 1y ago
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.
- pjc50 1y ago
  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.
  - layer8 1y ago
    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/advanced#request-smuggling-via-crlf-injection 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.
- arp242 1y ago
  It always seemed to me that converging everything to \n is relatively easy, whereas converging on \r\n is much harder. Existing \r\n files and protocols will continue to work: you just need to ignore the \r. For example something like SMTP can be modified from "lines must end in \r\n" to "lines must end in \n, and trailing \r must be ignored". All existing SMTP will continue to work, although it may be a while before all servers reliably support \n of course.
ummonk 1y ago
The fundamental problem is that we decided to reuse a teleprinter command data format as a format for storing textual data.

Of course we can, it's just that some people decide wrong.

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.

pjc50 1y ago
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.
- layer8 1y ago
  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/advanced#request-smuggling-via-crlf-injection 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.
arp242 1y ago
It always seemed to me that converging everything to \n is relatively easy, whereas converging on \r\n is much harder. Existing \r\n files and protocols will continue to work: you just need to ignore the \r. For example something like SMTP can be modified from "lines must end in \r\n" to "lines must end in \n, and trailing \r must be ignored". All existing SMTP will continue to work, although it may be a while before all servers reliably support \n of course.

ummonk 1y ago

The fundamental problem is that we decided to reuse a teleprinter command data format as a format for storing textual data.