---
name: msys-grep-instrument-traps
description: "Two MSYS/bash scan instruments that report CLEAN while measuring nothing — bash $'\\000' is an empty pattern, and MSYS grep core-dumps on multi -e patterns. Use python for any repo-wide scan whose GREEN is load-bearing."
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 7537c945-a83b-4fc2-bfd9-184eb364b28e
  modified: 2026-08-21T08:39:21.914Z
---

On this node (Windows/MSYS git-bash), two scanning instruments silently measure **nothing** and
read exactly like a clean result. Both bit me in one session, 2026-08-21.

1. **`grep -qa $'\000' "$f"` matches EVERY file.** Bash cannot represent NUL in a `$'…'` string, so
   `$'\000'` is the EMPTY string and the pattern matches everything. I "found" ~190 corrupt files;
   the real number was 1.
2. **MSYS `grep` ABORTS (core dumps) on the two-pattern form** `grep -i -e A -e B <file>` — it
   prints nothing, writes `grep.exe.stackdump`, and with `-l`/`-c` in a pipeline the crash looks
   identical to "no matches". I concluded "no files reference the private home" while the leak gate
   was failing on exactly that; the gate was right and my grep was dead.

**Why:** a scan whose GREEN is load-bearing (corruption sweeps, leak guards, coverage checks) must
prove it can still see a positive. Both failures produced the *reassuring* answer, which is the
direction that never gets questioned.

**How to apply:** for any repo-wide scan that gates a decision, use `python -` with explicit
`open(f,'rb')` and `in` checks — not bash grep. If you do use grep, give it a POSITIVE CONTROL in
the same run (a file you know matches) and fail when the control misses. `git grep` is also fine;
the crash is MSYS coreutils grep specifically. Same family as [[list-vs-predicate-assertions]]
(a predicate that reads green while measuring nothing) and the half-population trace in
[[v02532-verdict-not-catchall]] — an instrument that covers none of the population is
indistinguishable from one that covers all of it.

SIBLING, 2026-08-21 — A PIPE MASKS THE EXIT CODE, AND I SHIPPED ON IT: I ran `sh ci/run-gates.sh 2>&1 | tail -12`, read `$?`, saw 0, and reported "gates PASS" to the operator. That 0 was TAIL's. The gate had exited 1 the whole time (leak guard firing on a new plan file naming the private home) and the commit landed red. Any `cmd | tail`/`| head`/`| grep` reports the LAST stage's status — for a gate, capture to a file and read the bare exit code (`cmd > log 2>&1; echo $?`), never pipe it. Same family as the greps above: the instrument answered reassuringly about a question it was not measuring. Also the standing repo pattern when the guard fires on a JIT plan: add the file to EXCLUDES in ci/publish/mirror-public.sh WITH a rationale comment (precedent: the three other *-PLAN.md entries), since the durable half lives in traceable-reqs.toml which is already excluded.