Exit-code inversions: a binary-file match becomes exit 1 (not found), a missing search root becomes exit 0 (success), and files under hidden directories are invisible to `rtk find`

Three differences from the real tools where rtk's answer is not merely shorter — it is the opposite verdict.

*Provenance: AI-assisted source audit, human-directed, at v0.44.2 (700bdde). All three run side by side against the real GNU tools on this machine; outputs verbatim.*

1. A binary-file match is reported as "not found"

$ printf 'AKIA_SECRET\x00binary\n' > creds.bin

$ grep -rn AKIA creds.bin ; echo "exit=$?"
Binary file creds.bin matches
exit=0

$ rtk grep -rn AKIA creds.bin ; echo "exit=$?"
exit=1

src/cmds/system/search.rs:291 injects -I (--binary-files=without-match), which the user did not ask for. That suppresses the match — and because grep's exit 1 is the canonical "pattern not found", rtk asserts the opposite of the truth.

This matters most for the case people actually use grep's exit code for: if rtk grep -q AKIA . ; then now takes the wrong branch. A secret sitting in a .bin, a compiled artefact, or any file with a stray NUL is reported as absent, with a success-shaped exit.

-rl and -rc are unaffected (they still list creds.bin), so the mode that inverts is the plain search. Passing -a explicitly does restore the match.

2. A search root that does not exist returns exit 0

$ find /nope/nothere ; echo "exit=$?"
find: '/nope/nothere': No such file or directory
exit=1

$ rtk find /nope/nothere ; echo "exit=$?"
exit=0

Empty stdout, empty stderr, success. src/cmds/system/find_cmd.rs:232-235 does Err(_) => continue on walk errors, so "this path does not exist" and "this path exists and contains nothing" become the same answer — and the exit code affirms the search worked.

A typo'd path, a directory removed between steps, or a wrong assumption about the tree all read as "searched successfully, nothing there".

3. Files under hidden directories are invisible

$ find . -name '*.yml'
./.github/workflows/ci.yml

$ rtk find . -name '*.yml'
(nothing, exit 0)

find_cmd.rs:216-223 sets .hidden(!pattern.starts_with('.')), so any path component beginning with . is skipped unless the pattern itself starts with a dot. .github/, .circleci/, .config/, .vscode/ and their contents are unreachable.

Correcting something in my own reporting: I initially believed gitignored files were also invisible, because that walker sets .git_ignore(true) as well. They are not — in the same repository, with .gitignore containing *.log and secrets.txt, both rtk find . -name '*.log' → app.log and rtk find . -name 'secrets.txt' → secrets.txt returned their files normally. Only the hidden-path filter is live. I am flagging the correction because I nearly filed the wider claim.

Why these three together

All three share a shape: rtk answers a question with a confident negative that the underlying tool would have answered positively, and the exit code backs the wrong answer up. An agent has no way to distinguish "rtk searched and found nothing" from "rtk declined to look".

Suggested directions (untested — no programmer has reviewed these)

1. Do not inject -I. If binary output is genuinely unwanted in the summary, keep grep's own Binary file … matches line and its exit status — that line is one token and carries the whole answer.
2. Surface walk errors: report the failing root and exit non-zero, rather than continue. Distinguishing "not found" from "could not look" is the entire value of the exit code here.
3. Either honour hidden paths by default (real find does) or state the exclusion in the output, the way the +N more marker does for the result cap. --hidden is currently rejected as an unknown flag, so there is no way to ask for them.

Two smaller ones from the same comparison

• rtk find drops the trailing newline on its last line. With a final result of ไฟล์ไทย.txt, output ends ไฟล์ไทย.txt with no \n, so it concatenates with whatever prints next. Any $(rtk find …) piped into while read loses or corrupts the last entry.
• Error messages name a binary that does not exist. rtk grep -rn X /nope reports /usr/bin/grep: C:/Program Files/Git/nope: No such file or directory — the path in the message is not the path passed, and /usr/bin/grep is not a path on this machine. Exit code 2 is correct; the diagnostic sends the reader to the wrong file.