Difference between '\n' and '\r\n'

  • Yes yes, I am aware that '\n' writes a newline in UNIX while for Windows there is the two character sequence: '\r\n'. All this is very nice in theory, but my question is why? Why the carriage return character is extra in Windows? If UNIX can do it in \n why does it take Windows two characters to do this?

    I am reading David Beazley's Python book and he says:

    For example, on Windows, writing the character '\n' actually outputs the two- character sequence '\r\n' (and when reading the file back, '\r\n' is translated back into a single '\n' character).

    Why the extra effort?

    I will be honest. I have known the difference for a long time but have never bothered to ask WHY. I hope that is answered today.

    Thanks for your time.

    It should also be noted that Windows isn't the only one that uses `\r\n`. It's also used by most text-based internet protocols (e.g. SMTP, HTTP, etc) for largely the same reason as Windows (ie history).

    Also, when in Java and using format strings (e.g. `System.out.printf()` or `String.format()`) make sure you use `%n` as your CRLF for OS compatibility purposes. `\n` is deprecated.

    I've seen `\n\r` several times. (I think it was something from NetWare.)

    For information, on Linux, telnet sends `\r\n` and netcat sends `\n`.

    There are very few Windows programs that actually require CRLF. CRLF may be the default, but nearly everything will autodetect and use LF just fine. I have all my text editors on Windows configured to use LFs for all new files, and it's really not an issue.

  • Correct answer

    10 years ago

    Backward compatibility.

    Windows is backward compatible with MS-DOS (aggressively so, even) and MS-DOS used the CR-LF convention because MS-DOS was compatible with CP/M-80 (somewhat by accident) which used the CR-LF convention because that was how you drove a printer (because printers were originally computer controlled typewriters).

    Printers have a separate command to move the paper up one line to a new line, and a separate command for returning the carriage (where the paper was mounted) back to the left margin.

    That's why. And, yes, it is an annoyance, but it is part of the package deal that allowed MS-DOS to win over CP/M, and Windows 95 to win over all the other GUI's on top of DOS, and Windows XP to take over from Windows 98.

    (Note: Modern laser printers still have these commands because they too are backwards compatible with earlier printers - HP in particular do this well)

    For those unfamiliar with typewriters, here is a video showing how typing was done: http://www.youtube.com/watch?v=LJvGiU_UyEQ. Notice that the paper is first moved up, and then the carriage is returned, even if it happens in a simple movement. The ding notified the typist that the end was near, and to prepare for it.

    If Windows does write the newline character eventually, why do I need to explicitly take care of it?

    +1 for answer. I suspected it had something to do with typewriters, but hadn't hear it said before.

    How did Unix with its \n only used to work with those old days printer? I assume they did have Unix Consoles connected to typewriter type printers?

    @Senthil, in Unix the newline character is converted by the end driver. It is just a different design decision.

    @Senthil, to be precise, in Unix printers and terminals are abstracted in the operating system, and their description determines which byte sequences are generated for the device. CP/M had no such abstraction leaving it all to the program running - this is most likely because this was not needed by all programs so having it in the resident operating system would take away precious memory from programs not needing it. Remember that CP/M was designed for a 16 _Kilobyte_ system.

    "So a major design feature of what is arguably the world's most advanced transportation system was originally determined by the width of a horse's ass." And so it is with software as well. http://www.astrodigital.org/space/stshorse.html

    @thorbjorn - The point still holds :)

    @Ryan, not quite. It is an interesting story, but still wrong.

    Printers were so much better back then; https://www.youtube.com/watch?v=lTxqQ3ALVcU (Not at actually _printing_ of course)

    @user1249, actually, the point he made is *confirmed* by the article you linked. The only part that it 'debunks' is that there was somehow something "inevitable" about the chain of events in question taking place, and reaching the results which they ended up reaching. (e.g.: Had the South won the Civil War, their multi-gauge railroad system may have eventually adopted a *different* gauge as the standard, and that would have become the US standard. But they didn't, so the single-gauge northern rail system replaced the southern one. And it shared the gauge decided by the width of a horse.)

License under CC-BY-SA with attribution

Content dated before 6/26/2020 9:53 AM