shell-count-correctness

Shell Count Correctness

Load when: writing or reviewing a shell pipeline that counts lines, files, or occurrences — especially one that feeds a gate, a budget, or a report.

A wrong count does not crash. It returns a plausible smaller number, the gate goes green, and nobody looks again. Every rule here is falsifiable in one command, and each one fixed a real defect in this repo.

---

wc -l counts newlines, not lines

A file whose last line has no trailing newline reports one line fewer than it has.

printf 'a\nb\nc' > f.txt   # three lines, no trailing newline

wc -l < f.txt              # 2   <- WRONG
awk 'END{print NR}' f.txt  # 3   <- right
grep -c '' f.txt           # 3   <- also right, but see the exit-code trap below

Incorrect — a 501-line file passes a 500-line gate:

LINE_COUNT=$(wc -l < "$SKILL_MD" | tr -d ' ')
(( LINE_COUNT > 500 )) && fail

Correct:

LINE_COUNT=$(awk 'END{print NR}' "$SKILL_MD")
(( LINE_COUNT > 500 )) && fail

Prefer awk 'END{print NR}' over grep -c ''. grep -c exits 1 when the count is zero (an empty file), so under set -euo pipefail an empty input aborts the whole script. awk exits 0 and prints 0. This is a real regression trap — it was shipped and reverted in this repo before landing on awk.

printf '' > empty.md
set -e
grep -c '' empty.md        # prints 0, EXIT 1 -> set -e kills the script
awk 'END{print NR}' empty.md   # prints 0, EXIT 0 -> safe

Shipped here: 132 .md files in this repo lack a trailing newline, and the 500-line SKILL.md gate under-reported each of them by exactly one line.

---

xargs wc -l | tail -1 drops every batch but the last

xargs splits a long argument list into batches. wc prints a total line per batch, so tail -1 keeps only the final one.

# 6000 files x 10 lines = 60000
find . -name '*.txt' -print | xargs wc -l | tail -1   # 10000  <- WRONG (-83%)