Skip to content

ripgrep Footguns

Mistakes that cause missed results, false confidence, or broken search pipelines.


1. Forgetting rg skips .gitignore'd files by default

You search for a string you know exists in node_modules/ or .terraform/. rg returns nothing. You doubt the file exists. It does — rg just respects .gitignore by default.

Fix: Use rg --no-ignore to include gitignored files. Use rg -uu (double-unrestricted) to also include hidden files. Use rg -uuu to include binary files too.

Remember: The -u escalation ladder: -u = skip .gitignore, -uu = also include hidden files/dirs, -uuu = also include binary files. When debugging "I know this string exists but rg can't find it," start with rg -uuu and add --debug to see exactly which files are being skipped and why.


2. Forgetting rg skips hidden files by default

You search for something in .env, .bashrc, or .config/. No results. rg skips dotfiles and dot-directories by default.

Fix: Use rg --hidden to include hidden files. Or rg -uu for both hidden and gitignored. If you always want hidden files, add --hidden to your ~/.ripgreprc.


3. Using rg --replace thinking it modifies files

You run rg "old_value" --replace "new_value" expecting files to be modified. They are not. rg only previews replacements in output — it never modifies files.

Fix: Use rg -l "old_value" | xargs sed -i 's/old_value/new_value/g' to actually modify files. Or use sd (a dedicated find-and-replace tool). rg is a search tool, not an editor.


4. Regex metacharacters in the search pattern

You search for rg "error[0]" expecting the literal string error[0]. The brackets are interpreted as a regex character class. rg matches error0 but not error[0].

Fix: Use rg -F "error[0]" for fixed-string (literal) matching. Or escape the metacharacters: rg "error\[0\]". Common regex chars that need escaping: ., *, +, ?, [, ], (, ), {, }, |, \.


5. Missing results because of the default line buffer

You pipe a long-running command into rg: tail -f app.log | rg "ERROR". Nothing appears even though errors are occurring. The upstream command is buffering output by line, but rg's output is block-buffered when piped.

Fix: Use rg --line-buffered "ERROR" when piping rg's output to another command. Or use stdbuf -oL on the upstream command. This ensures matches appear immediately.


6. Glob patterns not working as expected

You run rg -g "*.yaml" "replicas" but miss files in subdirectories. Single * does not match directory separators. Files like devops/helm/values.yaml are skipped.

Fix: Use rg -g '**/*.yaml' for recursive matching. Or use the type filter rg -t yaml which handles this automatically. The ** glob matches across directory boundaries.


7. Smart case giving unexpected results

You have --smart-case in your config. You search rg "error" (all lowercase) — it matches Error, ERROR, and error. Then you search rg "Error" (mixed case) — it only matches Error exactly. The behavior change is confusing.

Fix: Understand the rule: all-lowercase patterns are case-insensitive, patterns with any uppercase are case-sensitive. If you want explicit control, use -i (always insensitive) or -s (always sensitive) instead of smart case.

Gotcha: Smart case is enabled by default if you have --smart-case in ~/.ripgreprc. This means rg "error" matches ERROR but rg "Error" does not match ERROR. If you're getting inconsistent results and don't remember setting this, check your RIPGREP_CONFIG_PATH and ~/.ripgreprc.


8. Counting matches vs counting files

You run rg -c "error" /var/log/ and get counts per file. You sum them and report "1,234 errors." But some lines have multiple matches and each is counted. The actual number of error lines may be different from the match count.

Fix: Use rg -c for match counts per file, rg -l for just file names with matches. If you need line counts (not match counts), use rg "error" | wc -l. Be clear about what you are counting.


9. Binary file skipping hiding results

You search for a string in a mixed directory. rg silently skips binary files (PDFs, images, compiled files). A config file that happens to have a binary header is also skipped. You miss a real match.

Fix: Use rg -uuu to search everything including binary files. Or use rg --binary to include binary files in search. Watch for the "binary file matches" warning — it means rg found something but did not show it.


10. Not using word boundaries for short patterns

You search rg "log" and match blog, catalog, dialog, logging, and backlog. You wanted only the word log but got every word containing those three letters.

Fix: Use rg -w "log" for word-boundary matching. This matches log only when surrounded by non-word characters. Essential for short, common strings like port, key, id, set.

Debug clue: If -w is too restrictive (misses logging), use explicit regex boundaries instead: rg "\blog" matches log and logging but not catalog. The \b boundary matches the transition between word and non-word characters, giving you more control than -w.