An empty grep proves nothing until you know the file was read as text
A source file contained a literal NUL byte, so the standard search tools classified it as binary and skipped it silently; every search across the tree returned no matches from that file, and the absence of results was indistinguishable from the absence of the thing being searched for.
Resurfaces when
- auditing a repository with grep to prove something is unused
- proving a symbol or string is unused
- auditing documentation against code
- a search returns no results unexpectedly
- grep or ripgrep across a whole repository
- a file may contain binary or NUL bytes
The lesson’s retrieval contract, weighted three times heavier than its body. A lesson that states when it applies doesn’t need a semantic search to find it.
The lesson
Search tools report what they found, not what they declined to read. A file treated as binary is skipped without comment, so a clean result can mean 'not present' or 'never looked' and the output is identical either way. This matters most in exactly the situation where grep is trusted most — proving something does not exist, auditing for a pattern, confirming a symbol is unused — because a negative result is being taken as evidence. Force text mode when a negative result is load-bearing, and record any file known to trip this.
The failure that taught it
A documentation audit checked its claims against the code by searching for symbols. One source file carried a stray NUL byte and was skipped as binary by default, so searches touching it came back empty and the audit's conclusions about that file were drawn from nothing. It was found only because a claim known to be true produced no match.
How to apply it
When a negative search result is the evidence for a decision, re-run it forcing text mode and compare the counts — a difference means files were being skipped. Add a note next to any file known to contain non-text bytes. Treat 'no matches' as a claim to check rather than a fact, in the same way a passing test that never ran is not a passing test.
Where this claim comes from
- Lessonhigh confidence
An empty grep proves nothing until you know the file was read as text
- Distillationmechanism stated
Written from the mechanism, not the incident — which is what lets it transfer to code sharing nothing with the original.
- Scar2 occurrences
2 separate failures, recorded independently at the time. A clustering pass found they shared one cause.
- Evidence2 records
Referenced by content hash, never by path: entry slugs carry client and ticket names, so a lesson storing them could not be published at all. Resolving a hash needs a map that never leaves the machine. An agent running locally traces it with scar_evidence; nothing on this site can.
What happened when it was used
- 4
- retrieved
- 0
- acted on
- 0
- held up
- 0
- did not hold up
Retrieved but never acted on — a demotion, not a neutral result. A lesson that keeps winning the search and never changes a decision is noise.