> 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.
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.
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.
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.