Interesting, I'm of the first kind, who uninstalled it quickly.
I use ctrl-r a lot, though I have no issue remembering exact portions of the commands, but that may just be me.
I'll give it another try.
In the same vein as ripgrep (rg), I recommand the author (and everybody else) to give fd-find (fd) a try as a replacement to find. It's much, much faster (multithreaded search), and has better defaults to use from the shell (doesn't complain about these permissions issues, and `fd abc` is equivalent to `find. -iname 'abc'`.
A few comments here mention it already, but I wanted to recommend it.
I loveeee fd! About the only time I reach for find is if I need to do something with printf.
I’ve noticed a bunch of CLI tools recently released written in rust that are along this same line of being snappy and well-written. Fclones, ripgrep, paru, fd, exa, to name a few. This probably has more to do with the type of developers the rust platform attracts, rather than the language itself (many awesome tools have been written in go recently as well). But yea, devs who have an interest in Linux and command line tools tend to be great IMO :)
If you don't want to install a tool just for this:
fs() { find -iname '*'"$1"'*' ; }
I don't really have big directories where speed would be a benefit, so haven't tried `fd` yet. I do use `ripgrep` but mostly for its features (like default recursive search respecting .gitignore, `-r` option, etc) over speed benefits.
time find ~ -type f
6.99 user 10.66 system 53% cpu 33.218 total
Second run: About the same (-0.32, -0.78, -1.929)
time fd --type f
4.61 user 11.27 system 120% cpu 13.172 total
Second run:
4.06 user 4.35 system 178% cpu 4.720 total
That's on an SSD. Admittedly, fd skips over hidden files and some directories by default. Adding them back (-u), it seems to take about the same time.
13.74 40.58 145% 37.324
Though it falls back to 13s if I disable colored output.
Piping these in wc -l to eliminate vt overhead, I have 1.4M matches, in about 5s for fd and 11s for find (warm runs, there is quite a bit of jitter). About 1s if I let fd skip hidden directories (.cache, .git, etc: 0.4M matches).
Point is, it's usually noticeably more responsive for realistic use-cases (and has colored output, parses .gitignore files, etc).
Just to explain a bit more... fzf is able to fuzzy-search a list for the input string. When it shows a list of directories, it relies on `find` to do so.
fzf is also more suited to interactive search, while fd is more of a "give me a list" thing.
I use ctrl-r a lot, though I have no issue remembering exact portions of the commands, but that may just be me.
I'll give it another try.
In the same vein as ripgrep (rg), I recommand the author (and everybody else) to give fd-find (fd) a try as a replacement to find. It's much, much faster (multithreaded search), and has better defaults to use from the shell (doesn't complain about these permissions issues, and `fd abc` is equivalent to `find. -iname 'abc'`.
A few comments here mention it already, but I wanted to recommend it.