3 ms·

> Not to mention the "opinionated" choice to ignore a dynamic set of files and directories That has bitten me a few times when using `rg`. Sometimes (but not o

> Not to mention the "opinionated" choice to ignore a dynamic set of files and directories That has bitten me a few times when using `rg`. Sometimes (but not often enough to remember the switch) I want to grep a lot of binary .so files for a string and am left wondering why nothing was found before just replacing rg with grep. Just calling `TOOL PATTERN` without switches is the most intuitive thing, and there I agree with `fd` to make `fd PATTERN` the default. Unlike BSD find which always needs at least a `.` to function. > chained patterns. The -or/-and and are indeed nice, but the -prune logic should get an update. Maybe when fd grows from 80 to 90% of use cases.

burntsushi 9y ago
If you're grepping binary files, then even with grep, you need to pass the `-a/--text` flag. ripgrep has the exact same flag. Protips: `rg -u` stop looking at `.gitignore` files. `rg -uu` searches hidden files/dirs. `rg -uuu` searches binary files.
- zeotroph 9y ago
  I actually forgot why exactly I switch from rg to grep for binary files, but after some tests I found the use case grep can but ripgrep can NOT do: $ grep FOO * Binary file libBar.so matches foo.txt:file with FOO in it rg/rg -u/rg -uu/ ignore libBar.so completely, whereas rg -uuu spits out binary garbage. Here grep's default behavior is what I expected: I want to know which binary files contain some symbol, details are less important (yes, I could use objdump or smarter tools, but grep is good enough 99% of the cases). rg -u should list the matching binary file, maybe rg -uu should walk a few (printable!) chars to the left and right of the binary match and -uuu should just assume it is text, i.e. the user is right and the auto-guess wrong.
  - burntsushi 9y ago
    That's an interesting use case. You could use the `-l` flag to only list file names that match in combination with `-a` I suppose. That wouldn't let you see the non-binary matched lines though. In any case, I filed an issue[1]. I think the UX is pretty tricky to get right though. [1] - https://github.com/BurntSushi/ripgrep/issues/631 https://github.com/BurntSushi/ripgrep/issues/631

burntsushi 9y ago

If you're grepping binary files, then even with grep, you need to pass the `-a/--text` flag. ripgrep has the exact same flag. Protips: `rg -u` stop looking at `.gitignore` files. `rg -uu` searches hidden files/dirs. `rg -uuu` searches binary files.

zeotroph 9y ago
I actually forgot why exactly I switch from rg to grep for binary files, but after some tests I found the use case grep can but ripgrep can NOT do: $ grep FOO * Binary file libBar.so matches foo.txt:file with FOO in it rg/rg -u/rg -uu/ ignore libBar.so completely, whereas rg -uuu spits out binary garbage. Here grep's default behavior is what I expected: I want to know which binary files contain some symbol, details are less important (yes, I could use objdump or smarter tools, but grep is good enough 99% of the cases). rg -u should list the matching binary file, maybe rg -uu should walk a few (printable!) chars to the left and right of the binary match and -uuu should just assume it is text, i.e. the user is right and the auto-guess wrong.
- burntsushi 9y ago
  That's an interesting use case. You could use the `-l` flag to only list file names that match in combination with `-a` I suppose. That wouldn't let you see the non-binary matched lines though. In any case, I filed an issue[1]. I think the UX is pretty tricky to get right though. [1] - https://github.com/BurntSushi/ripgrep/issues/631 https://github.com/BurntSushi/ripgrep/issues/631