Line Feed
LF (Line Feed) is ASCII code point 10 (0x0A), Unicode U+000A, and a control character. If you're seeing `^M` at the end of every line or a shell script that fails for no apparent reason, you're dealing with a line-ending mismatch — and LF is at the center of it. It moves the cursor down one line and is the standard line terminator on Unix, Linux, and macOS. The split happened decades ago and never healed: Unix uses bare `\n`, Windows uses `\r\n`. This mismatch silently corrupts diffs, breaks scripts, and confuses editors. Git manages it with `core.autocrlf`, a setting that itself causes confusion. In C-descended languages, `\n` may be translated to the platform's native line ending depending on whether the file was opened in text or binary mode. HTTP and SMTP require `\r\n` regardless of platform. LF originated in teletype practice, where it physically advanced the paper one line — a separate mechanical action from returning the print head to column one, which is why CR and LF both exist and why some systems still require the pair. UTF-8 encodes it as a single byte 0x0A, identical to its ASCII value. Unicode classifies it as Cc (Control, Other) under the official name LINE FEED. One of several Unicode line-ending characters alongside CR (U+000D), NEL (U+0085), and the line and paragraph separators (U+2028, U+2029), though in practice nearly everything on the modern web uses LF alone.
Technical Details
Code Example
</>
char *msg = "GET / HTTP/1.1\nHost: example.com\n\n";// LF separates header lines in this raw exampleint is_lf = (msg[14] == '\n'); // '\n' is ASCII 10
Frequently Asked Questions
LF (\n, ASCII 10) is Unix/macOS line ending. CR (\r, ASCII 13) was old Mac (pre-OS X). CRLF (\r\n) is Windows. The difference comes from typewriters: CR returns the carriage to column 1, LF advances the paper. Unix decided one character was enough.
It tells Git how to handle line endings. 'core.autocrlf true' converts CRLF to LF on commit and back to CRLF on checkout (for Windows). 'input' converts to LF on commit but keeps LF on checkout (for Mac/Linux). 'false' does nothing, risking mixed line endings.
This warning means Git is about to normalize your line endings, which is usually good. To suppress it without changing behavior, set 'core.safecrlf' to false. Ideally, add a .gitattributes file with '* text=auto' to enforce consistent handling across your team.
This classic error happens when you try to run a script saved with Windows line endings (CRLF) on Linux/macOS. The shell sees the invisible '\r' as part of the command name. Fix it by running 'dos2unix myscript.sh' or stripping the CR bytes.
Because they're invisible. A file with Windows CRLF endings opened on Linux shows ^M characters at line ends. Git diffs show every line as changed. Scripts fail with 'bad interpreter' errors. This single-byte difference has caused millions of hours of debugging.
Add a .gitattributes file with '* text=auto' to let Git normalize line endings. Use .editorconfig to set end_of_line for new files. For existing files, tools like dos2unix and unix2dos do batch conversion. The goal is consistency, not a specific style.
They're the same thing. ASCII called it Line Feed because it moved paper down one line on a printer. Programming languages adopted \n as the escape sequence. The C standard calls it 'newline' but the underlying byte is still ASCII 10 — just with a friendlier name.
Yes. Linux kernel and shell scripts strictly expect LF. If you mount a Windows file into a Docker container or run a CRLF script, it will almost certainly fail. Always ensure entrypoint scripts use LF line endings.