Thank you for the feedback.

> So, I would suggest that you don't call this an alternative to find; it's not. A replacement for shell globs, sure. A replacement for poor file finding in text editors, OK. Just... not find.

It's literally called "a simple [..] alternative to find" and the very first sentence in the README says that "it does not seek to mirror all of find's powerful functionality". I'm not sure anymore how far I have to back off until everyone will be okay with my "advertising" :-)

But in fact it does not seek to mirror _any_ of find's powerful functionality.

Maybe advertize it as "a better ls -R | grep -i"?

> The absense of -delete, -execdir, -mtime, and the ability to chain multiple patterns together for the non-trivial use-cases, means this is practically useless in most places where `find` is used in day-to-day work

Yeah except in most places where `find` is used in day-to-day work it is just for `find -iname 'foo'`. Anything fancier is probably less than 10% of uses. Here is my .bash_history:

find .

find .

find

find .

find . -name "debug.csv"

find .

man find

find . -type f

find . -iname "signal"

> The absense of -delete, -execdir, -mtime, and the ability to chain multiple patterns together for the non-trivial use-cases, means this is practically useless in most places where `find` is used in day-to-day work.

I completely agree with that.

And would in fact go slightly further: one of my huge annoyances with `find` is that I can never get alternative (-o) non-trivial patterns to work correctly, I think there's room for an alternative tool here but it should learn from set-theoretic API and make non-trivial predicates easy to write and test. Something like mercurial revsets — using fileset patterns and predicates instead of revs obviously — would be a godsend.

It took me a while to figure out `-o`. You need to use `\(` `\)`

    find . -type f \( -name \*.c -o -name \*.cc -o -name \*.cpp \)

That was also my understanding, but even with that I don't think I ever ended up getting such an expression right.

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

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.

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.

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

I'm with you in that I will probably not use this (the auto .gitignore reading freaks me out). Another elitist aside: I can usually tell that I won't want to use a tool when it has a mac os install option first under the downloads section on its page.

That said, the good thing about open source is you don't have to use it. I imagine the opinionated choices they made are popular amongst that crowd who seem like the types who mainly use the terminal to code--hence the .gitignore awareness; so, I imagine it's ok for others to use it if they find it makes themselves more productive for what they do. But, the good news is fd won't become a default anytime soon for that reason, so I have nothing to worry about this affecting me.

> Another elitist aside: I can usually tell that I won't want to use a tool when it has a mac os install option first under the downloads section on its page.

This is only because it's so much harder to support every possible Linux distro. I actually don't use macOS on my own, but 'Homebrew' seems like a really nice package manager. (Also, the first install option is via "cargo" which is platform independent.)

You can still use xargs without overhead :

> fd .py | xargs stat

Quick FYI: xargs is not the same as execdir; execdir executes the command in the same directory as the file. And to account for spaces in filenames (yay, OSX), your command starts getting a bit more complicated: fd -0 .py | xargs -0 stat

Thanks for the tips :)