The whole \r is archaic. It doesn't even behave properly in most cases. Just use \n everywhere and bite the lemon for a short while to fix your problems.

And if you believe \r\n is the way to go, please make sure \n\r also works as they should have the same results. (or \r\n\r\r\r\r for that matter)

But without \r how am I supposed to print to my typewriter over serial cable? Only half-joking, that's the setup my family had in the early 90's.

Send BELL characters and wait for human intervention

Why did they even decide to use two characters for the end of line? Seems bizarre. I could have imagined that `\r` and `\n` was a tossup. But why both?

Likely compatibility bugs going back decades (70s?). Probably with some terminal/teletype.

\r - returned teletype head to the start of a line

\n - move paper one line down

> The sequence CR+LF was commonly used on many early computer systems that had adopted Teletype machines—typically a Teletype Model 33 ASR—as a console device, because this sequence was required to position those printers at the start of a new line. The separation of newline into two functions concealed the fact that the print head could not return from the far right to the beginning of the next line in time to print the next character. Any character printed after a CR would often print as a smudge in the middle of the page while the print head was still moving the carriage back to the first position. "The solution was to make the newline two characters: CR to move the carriage to column one, and LF to move the paper up."[2] In fact, it was often necessary to send extra padding characters—extraneous CRs or NULs—which are ignored but give the print head time to move to the left margin. Many early video displays also required multiple character times to scroll the display.

https://en.wikipedia.org/wiki/Newline

It’s similar to an old school typewriter.

The handle does 2 things: return and feed. You can also just return by not pulling all the way or the other way around depending on the design

Which also let you do strikethrough and similar effects by typing over a line you already typed

It is known. Why didn’t Linux decide to do that though.

Oh well. It’s more important to well-actually your knowledge of typewriter characters than to explain the history of why Windows is apparently the only platform (not Linux, not Mac, probably not the BSDs) that had to take “backwards compatibility” into concern.

Carriage Return (\r) - move to start of line

Line Feed (\n) - move down 1 line

Essentially, when you're sending commands to teletypes, that's how you'd have to do it.

I know what the symbols mean and their original purpose. No one has answered why Windows and apparently only Windows acts like this. It’s not like Windows is the only platform that cares about hysterical raisins.

Typewriters is why

Thank you. I totally didn’t know what “linefeed” and “carriage return” mean.

\r\n is a standard though (in fact, it's arguably more of a standard than what Unix and C did), so you really can't just do something different and expect everyone to follow.

(For example, most text-based internet protocols such as HTTP use \r\n as a line separator/terminator, so refusing to put the \r will be incompatible for no reason.)

There are unices that use LFCR endings... computing is an endless bath in history

FWIW, and I know this doesn't really address your complaint: I use Windows and I've set all my text editors to use LF exclusively years ago and Things Are Great. No more weird Git autocrlf warnings, no quirks when copying files over to/from people on Macs or Linuxes, etc. Even Notepad supports LF line endings for quite a long time now - to my practical experience, there's little remaining in Windows that makes CRLF "the OS standard line ending".

I bet if someday VS Code's Windows build ships with LF default on new installations, people won't even notice.

I mean, at some point it did matter what the OS did when you pressed the "Enter" button. But this isn't really the case much anymore. VS Code catches that keypress, and inserts whatever "files.eol" is set to. Sublime does the same. I didn't check, but I assume every other IDE has this setting.

Similarly, the HTML spec, which is pretty nuts, makes browsers normalize my enters to LF characters as I type into this textarea here (I can check by reading the `value` property in devtools), but when it's submitted, it converts every LF to a CRLF because that's how HTML forms were once specced back in the day. Again though, what my OS considers to be "the standard newline" is simply not considered at all. Even CMD.EXE batch files support LF.

I don't really type newlines all that much outside IDEs and browsers (incl electron apps) and places like MS Word, all of which disregard what the OS does and insert their own thing. Maybe the terminal? I don't even know. I doubt it's very consequential.

EDIT: PSA the same holds for backslashes! Do Not Use Backslashes. Don't use "OS specific directory separator constants". It's not 1998, just type "/" - it just works.

> I bet if someday VS Code's Windows build ships with LF default on new installations, people won't even notice.

As with '/', they really ought to do this some day but won't.

> Even CMD.EXE batch files support LF.

I don't know if it is the case on Windows 11, but I have surely been bitten by CMD batch files using LF line endings. I don't remember the exact issue but it may have been the one bug affecting labels. [1]

[1]: https://www.dostips.com/forum/viewtopic.php?t=8988#p58888

I could never get visual studio (not code) to not use \r\n when editing a solution file via the gui