If an editor displays two rows but wc -l reports one, check whether the file ends with a newline before assuming that data has disappeared. GNU wc -l counts newline characters. A trailing fragment without a final newline is not included in that count, even though an editor may display it as another row.
This distinction matters when checking generated configuration files, text exports and logs. A newline count is useful evidence, but it is not by itself proof of a complete export, a successful transfer or the number of business records in a structured file.
Reproduce the difference without editing a file
Run these harmless commands in Bash on a system with GNU Coreutils. They send small strings directly to wc and do not create or change any files:
printf 'alpha
beta' | wc -l
printf 'alpha
beta
' | wc -l
printf 'alpha
beta' | wc -c
printf 'alpha
beta
' | wc -cThe newline counts are one and two, respectively. The byte counts are ten and eleven for these ASCII strings. The second version adds one newline byte; it does not add another word. The commands use printf deliberately so the terminating newline is controlled rather than supplied implicitly.
An empty input has no newline characters. A nonempty string with no newline also has a newline count of zero. That does not make the string empty. Conversely, one newline on its own contributes one to the count even though it contains no nonblank text.
Read an existing file without changing its bytes
wc -l < ./export.txt
wc -c < ./export.txtReplace the path with a trusted file you are authorised to read. Input redirection avoids adding the filename to the output. The commands inspect the file independently; a changing log can be different between the two reads. Work from an appropriate stable copy when consistency matters.
If the shell cannot open the file, preserve the error instead of treating the result as an empty export. A successful zero newline count and a failed attempt to read a pathname are different outcomes. Do not suppress error messages in an automated check without separately recording failure.
Do not convert newline counts into record counts blindly
The tempting workaround is to add one whenever a count looks low. That is wrong for empty files, files already ending in a newline and formats where physical lines are not records. Decide what you mean by a record before choosing the tool.
A CSV record, for example, may contain a quoted field with embedded newlines. Counting those characters cannot tell you how many parsed records exist. JSON documents can span many lines; a pretty-printed document and a compact document can represent the same data with very different counts.
Similarly, a terminal or editor can wrap a long physical line onto several screen rows. Visual wrapping does not insert newline bytes into the file. Compare the file format’s rules with the tool’s actual measurement, not just the number of visible rows.
Preserve evidence before normalising an export
Do not append a newline to the original simply to make a count match an expectation. Even a one-byte edit changes the file and can affect a checksum, a signed artefact or a downstream parser’s behaviour. If an application requires a terminating newline, establish that requirement, retain the original and make a separately named working copy using an authorised process.
Check the producing program’s completion status and the receiving application’s parser as separate questions. A file ending with a newline can still be truncated earlier, contain invalid records or be the wrong export. An absent final newline can be intentional and does not alone establish corruption.
For a different file-identity question, see checking whether two filenames refer to the same file with stat. Two names are not necessarily two independent copies; likewise, two visible rows are not necessarily two newline characters.
Quick troubleshooting checklist
- Confirm that the command is GNU wc and that you selected
-l, not a word or byte count. - Reproduce the final-newline distinction with controlled input.
- Keep read errors separate from a successful zero result.
- Check whether the format permits multiline records or a header row.
- Keep the original bytes and document any normalisation separately.
Does wc -l count blank lines? It counts their newline characters. Does wc -c count characters? It counts bytes; byte and character counts can differ with multibyte text. The ASCII example above avoids that ambiguity.
Source: The GNU Coreutils upstream manual source, in its wc invocation section, explicitly states that -l counts newline characters and excludes a trailing partial line. The same section distinguishes byte and character counts.
Safety: This tutorial is for educational purposes. Test carefully before production use. The site owner is not responsible for misuse, damage, data loss or production issues.
