A text file looks the same wherever you open it, until a script fails with a cryptic "bad interpreter" error, or a file shows up as a single long line, or every line ends with ^M. The cause is almost always the invisible character, or pair of characters, that marks the end of a line.
The three conventions
- LF (line feed,
\n, byte0x0A): used by Linux, macOS (since Mac OS X) and other Unix-like systems. - CRLF (carriage return plus line feed,
\r\n, bytes0x0D 0x0A): used by Windows and in many internet protocols and file formats, such as HTTP headers and email. - CR (carriage return,
\r, byte0x0D): used by classic Mac OS before OS X. It is rare now.
The names come from typewriters and teleprinters: the carriage return moved the print head to the start of the line, and the line feed advanced the paper. Windows kept both; Unix chose one.
What goes wrong
One long line. A file with LF endings opened in a very old Windows program, or a CR-only file in a modern editor, can appear as a single line because the program does not recognise that line break. Most modern editors, including Windows Notepad in recent versions, handle LF correctly.
^M at the end of lines. A CRLF file displayed in a Unix tool shows the carriage return as ^M (or \r).
Scripts that will not run. A shell script saved with CRLF endings fails on Linux and macOS with an error like /bin/bash^M: bad interpreter, because the interpreter name includes the carriage return. Fix the line endings.
Stray characters in values. In data and config files, a trailing carriage return can end up inside the last value on each line, causing failed comparisons and lookups, for instance in .env files or INI files.
Noisy diffs. If a project mixes line endings, version-control diffs show every line as changed.
Mixed endings. A file edited on different systems can contain both LF and CRLF, which causes odd behaviour in some programs.
How to see which one a file uses
- Most code editors show the line ending in the status bar (LF or CRLF) and let you change it.
- On Linux and macOS, the
filecommand reports "with CRLF line terminators" for CRLF files, andcat -A fileshows^M$at the end of CRLF lines and a plain$for LF. - Many editors have a "show whitespace" or "show line endings" option.
How to convert
- In an editor: use the line ending option in the status bar or menu, then save.
- With
dos2unixandunix2dos, if installed, which convert in place. - With
sed:sed -i 's/\r$//' fileremoves carriage returns on GNU systems. - With Git: the
core.autocrlfsetting and a.gitattributesfile such as* text=autocontrol whether Git converts line endings on checkout and commit, so a team on mixed systems keeps one convention in the repository. Specific files, like shell scripts, can be pinned to LF with*.sh text eol=lf.
Which should you use?
- Use LF for code, scripts, configuration and anything that runs on Unix-like systems or in containers. It is also fine on Windows with modern tools.
- Use CRLF only when a Windows-specific tool or format requires it. CSV files follow CRLF in RFC 4180, though most parsers accept LF too.
- Be consistent within a file and a project.
Files that care and files that do not
Plain prose, Markdown and most modern programming languages treat LF and CRLF the same. Shell scripts, some configuration formats, files with shebang lines, and strict parsers do not. If a file works on one machine and fails on another, check line endings along with encoding.
Editing safely
In the browser version of Docento's Text & Markdown Editor, the text area converts line breaks to LF while you edit, so a CRLF file downloaded from it comes back with LF endings. That is usually what you want for code and config, but if a Windows-only tool needs CRLF, convert the file afterwards with an editor option or unix2dos.
Takeaway
LF is the Unix convention, CRLF is Windows', and mismatches cause one-line files, ^M characters and scripts that will not run. Check the ending in your editor, convert with an editor option or dos2unix, and standardise on LF for code and config.
