GNU comm can show which names occur only in one text list and which occur in both. Its inputs must be sorted using the same collation rules. Just as importantly, a successful comparison returns zero even when the lists differ: its exit status reports command success, not equality.
This makes comm useful when reviewing two manually collected inventories, such as expected and observed job names. It is not a byte-integrity checker, and a match between names does not establish that the underlying jobs ran successfully. Decide what an entry means before comparing it.
Prepare comparable inputs before looking for differences
Use one complete name per line. Agree whether leading spaces, letter case and repeated entries are meaningful. Sorting does not silently resolve those interpretation questions. For a set of names, removing identical duplicate lines is reasonable; for an audit where repeated events matter, keep the duplicates and use a method designed for multiplicities.
Set the same locale for both sorts and the comparison. LC_ALL=C gives a reproducible byte-oriented ordering for this demonstration. It is not a promise of culturally appropriate ordering for human names. Changing a locale does not convert encodings or normalise visually similar Unicode text.
Try a disposable example without touching real inventories
The following Bash example creates a unique temporary directory. Run all five blocks in the same Bash session so the variable and cleanup trap remain available. These are invented demonstration entries, not measurements of a real machine.
work=$(mktemp -d) || exit 1; trap 'rm -rf -- "$work"' EXITprintf '%s\n' gamma alpha beta alpha > "$work/expected.txt"; printf '%s\n' delta gamma beta > "$work/observed.txt"LC_ALL=C sort -u -- "$work/expected.txt" > "$work/expected.sorted" && LC_ALL=C sort -u -- "$work/observed.txt" > "$work/observed.sorted"LC_ALL=C comm --check-order -23 -- "$work/expected.sorted" "$work/observed.sorted"LC_ALL=C comm --check-order -13 -- "$work/expected.sorted" "$work/observed.sorted"; LC_ALL=C comm --check-order -12 -- "$work/expected.sorted" "$work/observed.sorted"Stop if a preparation step fails; do not interpret results from missing or incomplete intermediate files. The first comparison should print alpha, which exists only in the expected list. The next prints delta, which exists only in the observed list. The final comparison prints beta and gamma on separate lines, the entries shared by both.
The duplicate alpha in the original expected list disappears because this example explicitly uses sort -u. That is a chosen set-comparison policy, not evidence that the original inventory contained no duplicates. The EXIT trap removes only the demonstration directory when this shell exits; keep any durable reports elsewhere.
Read column suppression rather than memorising guesses
Without suppression options, comm produces three columns: entries unique to the first file, entries unique to the second, then entries common to both. Tabs separate those columns. Leading tabs are therefore structural information, not accidental indentation.
The digits suppress columns. Option -23 hides columns two and three, leaving entries unique to the first file. Option -13 leaves only the second-file entries. Option -12 leaves the shared entries. Reversing the file arguments reverses the meaning of first-only and second-only; label saved outputs accordingly.
Check command success separately from list equality
Unlike some comparison tools, comm normally returns zero regardless of whether it printed differences. Do not write an automation condition that treats a zero status as proof the inventories match. First verify successful execution; then inspect the appropriate result stream for the question you actually asked.
The GNU –check-order option makes incorrectly ordered input an error. If ordering or reading fails, discard the comparison output, even if some lines were already printed. Do not add –nocheck-order merely to silence the diagnostic: forcing an invalid input order cannot make its result trustworthy.
For automation, also check each sorting step and avoid interpreting a downstream success as proof every upstream stage succeeded. Redirecting a report to a file may leave partial output on failure; label it incomplete until the command and input preparation have succeeded.
Checklist and related investigation
- Are both lists describing the same kind of entry and collection period?
- Were encoding, whitespace and duplicate policies agreed?
- Were inputs sorted with the same locale used by comm?
- Did the chosen column answer first-only, second-only or shared?
- Were execution errors checked before reading the result?
If matching names might refer to the same underlying filesystem object, that is a different question. See checking whether two Linux filenames are hard links to the same file.
Source and safety note
Source: the official GNU Coreutils manual source, section comm invocation. This tutorial is educational. Test carefully before production use. The site owner is not responsible for misuse, damage, data loss or production issues. Do not delete real inventory entries or operational resources merely because this text comparison lists them as unexpected.
