grep: -r / -rn rejected on 0.42.4 (and -rln returns a false "0 matches" on latest develop)

[EtaCassiopeia]

Using rtk 0.42.4 from Homebrew. rtk grep is one of the commands I use the most, but a couple of really common invocation shapes don't behave the way I'd expect.

-r (and -rn) get rejected outright

$ rtk grep -r "TODO" src
error: unexpected argument '-r' found

  tip: to pass '-r' as a value, use '-- -r'

Usage: rtk grep [OPTIONS] <PATTERN> [PATH] [EXTRA_ARGS]...

-rn fails the same way. Since rtk grep is always recursive anyway, I'd expect -r/--recursive to just be accepted and ignored, the same way -n/--line-numbers already is (there's even a comment in the code to that effect). Instead it falls all the way back to running plain grep completely unfiltered — which kind of defeats the point of using rtk in the first place, since -r/-rn is probably the single most common way people actually type a recursive grep.

I checked whether this was already fixed in develop before reporting — built it from source, and -r/-rn do work there now (looks like it happened as a side effect of restructuring the arg parsing, not sure if intentional). So this might just need backporting/releasing rather than a new fix.

-rln on develop: silent false "0 matches"

While checking the above, I found -rln still misbehaves on develop, just differently:

$ rtk grep -rln "TODO" src
0 matches in 0 files

There are definitely matches there (plain grep confirms it). Dug a bit further — looks like the combined short flags get merged into one token (e.g. -rln → -ln after the recursive flag is stripped), and the check for "format" flags like -l (files-with-matches) only looks for it as a standalone arg, not bundled inside a cluster like that. So rtk doesn't realize -l changed rg's output shape entirely, tries to parse it as normal match lines, and silently gets nothing — which looks exactly like "no matches found" instead of "something's off here."

I have a small fix for the second one and will open a PR. Mentioning both here since they're related (same command, same general area) and the first one might just need a release rather than code changes.

[alexisLefebvre]

Confirming the -rln false-zero on 0.42.2 (Linux, .deb), and narrowing the trigger: it's the bundled short-flag cluster, not -l+-n semantically. Self-contained repro:

mkdir -p /tmp/rtk-grep && cd /tmp/rtk-grep
printf 'alpha\nfoo bar\nbaz\n'        > a.txt
printf 'no match here\nanother foo\n' > b.txt
printf 'nothing\n'                    > c.txt

grep -rln foo .          # real grep, ground truth -> lists a.txt, b.txt
rtk grep -rln foo .      # "0 matches in 0 files"
rtk grep -r -l -n foo .  # separated -> lists a.txt, b.txt
rtk grep -rl  foo .      # no -n     -> lists a.txt, b.txt

So separated -l -n (either order) works; only the bundled cluster fails. Matches your analysis of the -rln false-zero — the -l check matches a standalone token but not -l inside -ln/-rln, so files-with-matches output is parsed with the wrong format and collapses to zero.

Two notes for 0.42.2: bundled -ln also fails (not just -rln), so any fix should cover the general clustered case, not just the -r-prefixed one. And -r/-rn are accepted on 0.42.2 — the 0.42.4 rejection you hit isn't present here.

Suggested fix (in case it differs from your PR): expand bundled short flags before format-flag detection (-rln -> -r -l -n).

🤖 Generated with Claude Code

---

As a workaround, I added this to my ~/.claude/CLAUDE.md:

- Do not bundle `grep` short flags — bundled `-l` (e.g. `-rln`, `-ln`) returns a false `0 matches` under the rtk hook (rtk-ai/rtk#2543). Separate them: `grep -r -l -n`.