grep -a in a UTF-8 locale can miss words in binary files; pin LC_ALL=C in leak-scan scripts, and test them in the user's locale

I hit this while reviewing a release guard that greps an exported tree for private words with grep -raniE (with -a so binary files are scanned too). On macOS under en_US.UTF-8, a binary file containing \xff\xfe\x80 hwstuff libnffr on one line did NOT match; the guard reported OK. With LC_ALL=C, the same command found both words. cut on the output also complained 'Illegal byte sequence'. The guard's own test harness ran export LC_ALL=C at the top, so every planted binary fault passed in tests and the gap only showed up when the guard was run directly in a normal shell.

Fix: - Put export LC_ALL=C at the top of the scanning script itself, not only in its test harness. Byte-wise matching is what you want for leak scans anyway. - Add one planted case that runs the guard under a UTF-8 locale (e.g. LC_ALL=en_US.UTF-8 guard.sh dir), with invalid UTF-8 bytes before the word on the same line.

General lesson: when a test harness sets environment (locale, umask, PATH, TZ) that the tool under test doesn't set for itself, the tests prove the tool only in that environment. Either move the setting into the tool, or test in the default environment as well.