Difference between CR LF, LF and CR line break types
I’d like to know the difference (with examples if possible) between CR LF (Windows), LF (Unix) and CR (Macintosh) line break types.
Very similar, but not an exact duplicate. \n is typically represented by a linefeed, but it’s not necessarily a linefeed.
CR and LF are ASCII and Unicode control characters while \r and \n are abstractions used in certain programming languages. Closing this question glosses over fundamental differences between the questions and perpetuates misinformation.
@AdrianMcCarthy It’s a problem with the way close votes act as answers in a way; an answer claiming the two were the same could be downvoted and then greyed out as very, very wrong, but it only takes 4 agreeing votes (comparable to upvotes) to have a very wrong close happen, with no way to counter the vote until after it’s happened.
This formulation of the question is admittedly better, but it is still for all practical purposes the same question.
10 Answers 10
CR and LF are control characters, respectively coded 0x0D (13 decimal) and 0x0A (10 decimal).
They are used to mark a line break in a text file. As you indicated, Windows uses two characters the CR LF sequence; Unix (and macOS starting with Mac OS X 10.0) only uses LF; and the classic Mac OS (before 10.0) used CR.
An apocryphal historical perspective:
As indicated by Peter, CR = Carriage Return and LF = Line Feed, two expressions have their roots in the old typewriters / TTY. LF moved the paper up (but kept the horizontal position identical) and CR brought back the «carriage» so that the next character typed would be at the leftmost position on the paper (but on the same line). CR+LF was doing both, i.e., preparing to type a new line. As time went by the physical semantics of the codes were not applicable, and as memory and floppy disk space were at a premium, some OS designers decided to only use one of the characters, they just didn’t communicate very well with one another 😉
Most modern text editors and text-oriented applications offer options/settings, etc. that allow the automatic detection of the file’s end-of-line convention and to display it accordingly.
so actually Windows is the only OS that uses these characters properly, Carriage Return, followed by a Line Feed.
Would it be accurate, then, to say that a text file created on Windows is the most compatible of the three i.e. the most likely to display on all three OS subsets?
@Hashim it might display properly but trying to run a textual shell script with carriage returns will usually result in an error
Rolf — that statement assumes that keeping old terminology/technology in new technology is correct. CRLF = 2 bytes. CR = 1, LF = 1. With as often as they are used, that actually translates to a huge amount of data. Once again, Windows has chosen to be different from the entirety of the *NIX world.
This is a good summary I found:
The Carriage Return (CR) character ( 0x0D , \r ) moves the cursor to the beginning of the line without advancing to the next line. This character is used as a new line character in Commodore and early Macintosh operating systems (Mac OS 9 and earlier).
The Line Feed (LF) character ( 0x0A , \n ) moves the cursor down to the next line without returning to the beginning of the line. This character is used as a new line character in Unix-based systems (Linux, Mac OS X, etc.)
The End of Line (EOL) sequence ( 0x0D 0x0A , \r\n ) is actually two ASCII characters, a combination of the CR and LF characters. It moves the cursor both down to the next line and to the beginning of that line. This character is used as a new line character in most other non-Unix operating systems including Microsoft Windows, Symbian and others.
The «vertical tab»-character moves the cursor down and keep the position in the line, not the LF-character. The LF is EOL.
@Vicrobot Developers will often split a string or perform other operations with the exact sequence \r\n , so \n\r would not match. Also one would think that text editors also treat the two characters as one sequence and don’t separatly go «oh, now I have to go down one line» and «oh, now I have to move to the front». Were it so then yes, you could freely swap the order around
It’s really just about which bytes are stored in a file. CR is a bytecode for carriage return (from the days of typewriters) and LF similarly, for line feed. It just refers to the bytes that are placed as end-of-line markers.
There is way more information, as always, on Wikipedia.
I think it’s also useful to mention that CR is the escape character \r and LF is the escape character \n . In addition, Wikipedia:Newline.
In Simple words CR and LF is just end of line and new line according to this link , is this correct ?
@shaijut CR stands for Carriage Return. That was what returned the carriage on typewriters. So, mostly correct.
The superior LFCR option is sadly missing. Its benefit is that by doing the Line Feed first, the Selectric golfball can’t smear the just printed line with still fresh ink upon executing the Carriage Return
Actually, it’s not a typewriter but «teletype», old computer client terminals with mechanical print heads and paper, where CR/LF were required for computers to behave properly. If you just did CR, you would have a bunch of characters on top of each other on a paper. If you just did LF, your text lines would slowly migrate to the right on the paper. CR/LF were required for proper teletype based computing. An old Star Trek game would dump «F
Carriage Return (Mac pre-OS X)
Line Feed (Linux, Mac OS X)
Carriage Return and Line Feed (Windows)
If you see ASCII code in a strange format, they are merely the number 13 and 10 in a different radix/base, usually base 8 (octal) or base 16 (hexadecimal).
The \r and \n only works in some programming languages, although it seems to be universal among programming languages that use backslash to indicate special characters.
Jeff Atwood has a blog post about this: The Great Newline Schism
The sequence CR+LF was in common use on many early computer systems that had adopted teletype machines, typically an ASR33, as a console device, because this sequence was required to position those printers at the start of a new line. On these systems, text was often routinely composed to be compatible with these printers, since the concept of device drivers hiding such hardware details from the application was not yet well developed; applications had to talk directly to the teletype machine and follow its conventions. The separation of the two functions concealed the fact that the print head could not return from the far right to the beginning of the next line in one-character time. That is why the sequence was always sent with the CR first. In fact, it was often necessary to send extra characters (extraneous CRs or NULs, which are ignored) to give the print head time to move to the left margin. Even after teletypes were replaced by computer terminals with higher baud rates, many operating systems still supported automatic sending of these fill characters, for compatibility with cheaper terminals that required multiple character times to scroll the display.
End of line (new line) escapes in Bash
I am not trying to echo a new line. I am wondering why \ is able to new line character ( \n ) which has two character instead of just escape the backslash in the new line character and produce the literal of \n .
Hmm, still not sure I understand your question. Perhaps it will help to know that \n is not really a newline character — it is an escape sequence that represents a newline (which is just one character in Linux). The \ at the end of a line escapes the actual newline character that you type in using the enter key.
@MarkkuK, thank you! this actually answers my question. I always thought \n is the new line character it self. That’s why I don’t understand why a backslash can escape two characters. Sorry about the bad phrasing.
As a technical addendum to @MarkkuK.’s comment, you can see the newline/linefeed character is a single ASCII value ( 10 ) on an ASCII table.
2 Answers 2
Actually, \n is not really a newline character—it is an escape sequence that represents a newline (which is just one character in Linux). The \ at the end of a line escapes the actual newline character that you type in using the enter key. You can look at what ASCII values represent different characters using hexdump:
%echo $'\\n' \n %echo $'\\n' | hexdump -C 00000000 5c 6e 0a |\n.| 00000003 You will notice that echo printed out 3 characters: \ (5c), n (6e), and a newline (0a). You will also notice that on the right hand side of the hexdump output, newline shows up as a «.», because it is considered a non-printing character.
Close, but if you avoid doubling up the ` and include the -n` parameter to echo to avoid the implicit newline then you get a newline character. sh echo -n $’\n’ | hexdump -C Which results in: «` 00000000 0a |.| 00000001 «`
Newline is the name given in the UNIX world to a character that ends a line in a line-oriented file (or in a terminal). In the UNIX/Linux world this corresponds to the ASCII linefeed character.
Different systems use different conventions to end lines: Windows uses a sequence of carriage return and line feed, while Mac originally used a single carriage return. This confusion stems from the fact that these were originally commands needed to move a printer’s print head to the beginning of a new line.
\n is a conventional way of expressing the end of line character in code, again originally in the UNIX world, more precisely in the C language. Note that when reading a text file C reads a single newline character even on systems where this is really a two character sequence.
How are \n and \r handled differently on Linux and Windows?
I think \n moves the needle down, and \r moves the needle to the beginning of a line (left align)? I’m not sure, though. So, if I’m wrong please correct me. Anyway, I was told that Windows and Linux handle newlines and carriage returns differently. I would like to know how they handle them differently and some places where it’s important to remember. Thanks for answering.
Don’t call them \r and \n , since how \n is handled depends on where you’re using it. Better to call them CR and LF .
Ignacio, those acronyms have no meaning to me. What do you call this :/? OH. LINE FEED and CARRIAGE RETURN. Thanks, sleske.
@IgnacioVazquez-Abrams C doesn’t rewrite the ASCII table though. I agree \n may not function as a line feed but that doesn’t mean it’s not the LF character. (more of a question since I know you know more than me)
4 Answers 4
I think \n moves the needle down, and \r moves the needle to the beginning of a line (left align)? I’m not sure, though
This is true, more or less, but mostly a historical curiosity. Originally, linefeed (LF) was used to advance the paper by one line on printers and hardcopy terminals (teleprinters); carriage return (CR) returned the print head to the start of the line.
This probably still works on modern printers when used in «text mode», but is otherwise of little relevance today.
Anyway, I was told that Windows and Linux handle newlines and carriage returns differently.
The difference is simply: OS designers had to choose how to represent the start of a new line in text in computer files. For various historical reasons, in the Unix/Linux world a single LF character was chosen as the newline marker; MS-DOS chose CR+LF, and Windows inherited this. Thus different platforms use different conventions.
In practice, this is becoming less and less of a problem. The newline marker is really only relevant for pograms that process «plain text», and there are not that many — it mostly only affects program source code, configuration files, and some simple text files with documentation. Nowadays most programs handling these kinds of files (editors, compilers etc.) can handle both newline conventions, so it does not matter which one you choose.
There are some cases where tools insist on «their» newline convention (e.g. Unix shell scripts must not use CR+LF), in which case you must use the right one.