fix(grep): surface error on exit code >= 2 instead of false "0 matches"

[ousamabenyounes]

Summary

rtk grep prints "0 matches for ''" when the underlying search tool exits with an error code >= 2, even when matches exist and the tool simply failed to run. This is a false negative — LLM agents interpret it as a clean empty result and act on incorrect information.

Root cause: grep_cmd.rs:386-399 handled only the narrow case exit_code == 2 && stderr non-empty. grep/rg convention: exit 1 = no match (normal), exit >= 2 = real error (bad regex, binary crash, missing tool). Any error exit that fell outside the narrow window silently became "0 matches".

Fix: Broadened the gate to exit_code >= 2. All error exits now surface to stderr (prefixed with the exit code for diagnostics) and never print the misleading "0 matches" message. Exit 0 and 1 behavior is unchanged.

Fixes #2461

Test verification (RED → GREEN)

With the fix reverted, the new test fails (RED):

running 1 test
test grep_error_exit_code_no_false_negative ... FAILED

---- grep_error_exit_code_no_false_negative stdout ----
thread 'grep_error_exit_code_no_false_negative' panicked at tests/grep_error_test.rs:50:5:
ERROR exit MUST NOT claim '0 matches' (false negative).
stdout: 0 matches for 'hello'
stderr: 

failures:
    grep_error_exit_code_no_false_negative

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.02s

With the fix applied, the test passes (GREEN):

running 1 test
test grep_error_exit_code_no_false_negative ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.01s

Full baseline: 2196 tests pass, 0 fail (2195 existing + 1 new).

🤖 Generated with Claude Code

[hgunduzoglu]

Checked this out and tested locally (macOS arm64). The core fix is correct — broadening the gate to exit_code >= 2 matches grep/rg convention, and all three paths behave right:

rg exit	meaning	before	this PR
0	matches	grouped output	grouped output ✓
1	no match	0 matches	0 matches, exit 1 ✓ (legit empty result preserved)
≥2	real error	0 matches (false negative)	grep failed with exit code N on stderr, exit propagated ✓

Verified with a fake rg exiting 2: it now surfaces grep failed with exit code 2 and exits 2 instead of the misleading 0 matches. The new integration test passes here. Nice — this closes a genuine false-negative footgun.

One blocker for CI, though: tests/grep_error_test.rs has an unconditional use std::os::unix::fs::PermissionsExt; (line 6) with no cfg(unix) gate. std::os::unix doesn't exist on Windows, so the integration-test crate will fail to compile on the Windows CI target (RTK ships a Windows build, and cli-testing.md marks cross-platform a 🔴 critical concern). It's the only file under tests/ that touches std::os::unix.

Two small options:

• Gate the whole file: add #![cfg(unix)] at the top (simplest — the test simulates a broken rg via a chmod'd shell script, which is unix-only anyway), or
• #[cfg(unix)] on the test fn + #[cfg(unix)] use std::os::unix::....

Either keeps the Windows build green while preserving the unix coverage. Everything else looks good — the fix itself is solid and well-targeted.

[ousamabenyounes]

Thanks for the review @hgunduzoglu — agreed, that's a real Windows compile break, not a nit. Fixed in 6eaa4a3 with option 1: #![cfg(unix)] at the top of tests/grep_error_test.rs. The test simulates a broken rg via a chmod'd shell script (from_mode / PermissionsExt), so the whole file is unix-only by nature — gating it keeps the Windows CI target green while preserving the unix coverage.

Verified: cross-check against x86_64-pc-windows-gnu now compiles clean (was E0433: could not find unix in os), and the Linux test still passes 1/1.

[KuSh]

LGTM thanks!