A simple, fast and user-friendly alternative to ‘find’

Fd and ripgrep&#x2F;rg are the two &quot;new&quot; alternatives I use on a regular basis, and which are just huge improvements to life. Both of these find&#x2F;search programs respect your .gitignore files, which helps enormously &amp; makes searching my department&#x27;s entire codebase really fast.<p>Fd is featured on Julia Evans&#x27; recent &quot;New(ish) command line tools&quot;[1]<p>[1] <a href="https:&#x2F;&#x2F;jvns.ca&#x2F;blog&#x2F;2022&#x2F;04&#x2F;12&#x2F;a-list-of-new-ish--command-line-tools&#x2F;" rel="nofollow">https:&#x2F;&#x2F;jvns.ca&#x2F;blog&#x2F;2022&#x2F;04&#x2F;12&#x2F;a-list-of-new-ish--command-l...</a> <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=31009313" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=31009313</a> (760 points, 37d ago, 244 comments)

The singular habit I picked up way back in the day was to simply cope with what was available.<p>There&#x27;s all sorts of utilities and such. Emacs was a grand example at the time as well. Lots of better mousetraps.<p>But when you bounce around to a lot of different machines, machines not necessarily in your control, &quot;lowest common denominator&quot; really starts to rear its ugly head.<p>That vast majority of my command line concoctions are burned into muscle memory.<p>Today, I think the base line install of modern *nixes are higher than they were back in the day, but the maxim still applies of working with what they have out of the box.

I want to love fd - I&#x27;m a big believer in the idea that CLIs don&#x27;t <i>have</i> to be scary, intimidating things (see normals using Slack with &#x2F;commands and keyboard shortcuts), and find has a gigantic hairball of a UI.<p>The thing is, though, I know find well enough to not notice the terrible UI that much, and I know I can rely on it being everywhere. With fd that isn&#x27;t true.<p>So it&#x27;s hard for me to justify making the move.<p>Same thing happens with things like the fish and oil shells - I have little doubt their UX is better than Bash&#x27;s, but Bash is pretty ubiquitous.<p>Emacs has this problem too, as an Emacs user. The UX is completely alien by current standards, but if you update the defaults you&#x27;ll break a lot of people&#x27;s existing configs.<p>How do you get around backwards compatibility &#x2F; universality UX roadblocks like this?

It feels like we&#x27;re in a third wave of innovation in Unix CLI tools. The first was from BSD in the late 70s&#x2F;early 80s which considerably improved the original Unix utilities, then the GNU tools rewrite in the late 80s, then there were the dark ages of System V. I give ack (and Andy) credit for starting this latest wave around 2005 but it&#x27;s really taken off lately with tools being rewritten in Rust and challenging the old status quo.

I love fd, but somehow I always get tripped up on this:<p><pre><code> fd # prints tree of current directory fd somedir&#x2F; # results in an error find # prints tree of current directory find somedir&#x2F; # prints tree of somedir&#x2F;</code></pre>

I like the contemporary alternative to the classics. They make a lot of thing so much easier.<p>I have a little mental block, though. It&#x27;s related to the realities of the stuff I work on. Since I find myself logged into other people systems, keeping the old, standard tools hot in my head does really take some of the load off. It&#x27;s a pretty common refrain, but it&#x27;s real and practical when you&#x27;ve got embedded systems, bsds, linuxes, macs, etc. Even the difference between gnu and mac is clunky when I don&#x27;t practice enough.<p>For the same reason, with the notable exception of git, I use practically no aliases.<p>If I could invent a product, maybe it would be one that enables effectively &quot;forwarding&quot; CLIs to a remote host shell.

I find `find` so difficult to use that I usually do `find . | grep pattern` when I need to search for a file name.

Maybe I’m just old fashioned but all these new command line utilities strike me as solutions in search of a problem.<p>Standard ‘find’ works great. It finds files. It can filter by any criteria I have ever had to look for and the syntax seems very intuitive to me (maybe I am just used to it). It is flexible and powerful.<p>I’d love to be told I’m wrong, because I feel like I’m missing something.

One thing to remember is that these fun utils won&#x27;t exist on production servers. You also don&#x27;t want them there for obvious reasons. I find it better to use the most commonly available set of unix tools and I end up being far more effective due to that.

Hmm, I already have a shell alias that does 90% of this. Doesn&#x27;t parse .gitignore, but it&#x27;s not a big problem for me. If it was I&#x27;d do `make clean` in the project.<p>This is always installed and ready to go on any box I have my dotfiles.<p>I suppose that is why it is hard for these perfectly-good improvements have a hard time getting traction. Because the older stuff is still so flexible.

That are a lot of dependencies for such a simple tool. I&#x27;m a Rust user myself, but some of those dependencies really should be part of a good standard lib. Actually, the NPM like ecosystem is my biggest pain point with Rust.<p>[dependencies]<p>ansi_term = &quot;0.12&quot;<p>atty = &quot;0.2&quot;<p>ignore = &quot;0.4.3&quot;<p>num_cpus = &quot;1.13&quot;<p>regex = &quot;1.5.5&quot;<p>regex-syntax = &quot;0.6&quot;<p>ctrlc = &quot;3.2&quot;<p>humantime = &quot;2.1&quot;<p>lscolors = &quot;0.9&quot;<p>globset = &quot;0.4&quot;<p>anyhow = &quot;1.0&quot;<p>dirs-next = &quot;2.0&quot;<p>normpath = &quot;0.3.2&quot;<p>chrono = &quot;0.4&quot;<p>once_cell = &quot;1.10.0&quot;<p>[dependencies.clap]<p>version = &quot;3.1&quot;<p>features = [&quot;suggestions&quot;, &quot;color&quot;, &quot;wrap_help&quot;, &quot;cargo&quot;, &quot;unstable-grouped&quot;]

I just want my entire file system stored in Sqlite so I can query it myself

I use find all the time, but it is such a strange beast - it&#x27;s as if there were a meeting among all the standard Unix utilities on look and feel and find missed the memo. But it&#x27;s ubiquitous and I&#x27;m too old to change horses now anyway.

Why would the tool want to ignore patterns in a .gitignore? It isn&#x27;t a git tool...

Hey, fd. I don&#x27;t use it normally, but it ended up being the easiest and fastest tool for me to delete ~100 million empty files off my disk (a weird situation). It has threading and command execution built in, so I could saturate my cpu pretty easily doing the deletes with `fd -tf --threads=64 --exec r m {}` (I put the space in the rm command on purpose for posting).

I don&#x27;t use `fd` on the command line because I have very ingrained `find` muscle memory, but it&#x27;s really made using `projectile-find-file` in Emacs totally usable with the huge monorepos I deal with at work. The same goes for `rg`, I love using it with `consult-ripgrep` in Emacs for searching through mountains of code.

&gt; The command name is 50% shorter* than find :-).<p>I love this but if enough new tools keep doing this I might have to change some of my bash aliases :(

I use fd and rg a lot, integrated them with my scripts and even have some of them bound to keys.<p>Insanely good and fast programs. Zero regrets.<p>For a fuzzy finder I recently replaced fzf with peco. I like it better, it&#x27;s very customizable.

I&#x27;m seriously curious, is this the first time this link is being submitted?<p>Frequently, I try to submit a link, and it shows up as having been submitted. And I&#x27;m quite certain a tool as popular as fd has been featured on hn before. So either, somehow this particular link has never been submitted (doubtful), hn allows resubmitting a link after some amount of time, or the link resubmit prevention logic doesn&#x27;t apply to certain users?

Usually when I can&#x27;t be bothered to remind myself the syntax for find, my go to these days is `echo **&#x2F;*pattern*`. Of course, this is mainly just for small searches.

I would love a `find` with reverse polish notation, also known as postfix notation. Something like:<p><pre><code> find . --name this --name that --or </code></pre> or, for more complex:<p><pre><code> find . --name this --name that --or --modified 2022-05-20 --and </code></pre> I have some little personal CRUD apps and this sort of postfix notation works very well for them.<p>I could write something like this but haven&#x27;t gotten motivated to do it though.

Windows test comparison on my machine - for finding all .jpg in my D: drive<p>1 - classic command prompt: &quot;D:\&gt;dir &#x2F;s &#x2F;b *.jpg &gt; 2.txt&quot; - time 5 seconds (4581 files)<p>2 - this little gizmo: &quot;D:\&gt;fd -e jpg &gt; 1.txt&quot; - time 1 second (same 4581 files)<p>Conclusion: I have a new tool dropped in my System32 folder from now on. Thank you David Peter

This didn&#x27;t really sound like something I need until I got to the `{.}` syntax, which solves a problem I was just trying and failing to solve with gnu find ten minutes ago (namely that there seems to be no convenient way to use the basename of the match in an exec statement, eg. bash&#x27;s `${file##*.}` syntax).

Well this is saving me a ton of time as I&#x27;m basically migrating UID ownership of files for NFS shares that dates back to the 90&#x27;s. According to my rough benchmarks between find and fd, fd is ~3 times faster.

See this for a collection of alternatives for a modern unix commands. <a href="https:&#x2F;&#x2F;github.com&#x2F;ibraheemdev&#x2F;modern-unix" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ibraheemdev&#x2F;modern-unix</a>

Haven&#x27;t there been unresolved security issues with chrono, a crate this one depends on?<p>Chrono hasn&#x27;t been updated for almost 2 years. Is the issue resolved or is there a security risk in using fd?

How does it run faster than find? Can I manually implement that speedup using standard unix tools? I need to run find a lot on many machines I don&#x27;t have access to install anything on.

Discussed in 2017: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=15429390" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=15429390</a> (215 comments)

I want a user friendly alternative to find&#x27;s companion xargs.

Would it make sense to create a utils package with all these new rust based utilities? Something like &quot;rustutils&quot; with a resemblance to &quot;coreutils&quot;.

There are some Unix tools I never get around to memorizing the syntax of, and always end up searching &quot;how to&quot;s. find is definitively one of them.

Find is a powerful command but one for which it is hard to find good examples beyond the basics.<p>So I&#x27;m glad for these new kinds of CLI tools.

I don&#x27;t like find. Nor do I like vi (not vim, vi) and&#x2F;or maybe others. I don&#x27;t wish to stamp on someone&#x27;s parade who&#x27;s more accomplished than I am. But I think these &quot;new&quot; tools miss the point.<p>I use vi because I know it exists on every(?) system ever. It&#x27;s not like I go out of my way seeking vi. I feel the feeling is similar for find. It works. It works well. It works the same on all systems I work on.<p>Would I go out of my way to install find on my system? Probably not.

Does fd solve the annoying “the order of the command line arguments matters a ton” approach that find uses?

Oh, nice. Currently I just have myshell alias `fn` to `find -name $argv` but this looks cool.

And another one, because I&#x27;ve read ncdu so much. dua is very nice as well.

Because no one mentioned it. procs. I love it as ps&#x2F;top replacement.

find is one of those tools that has me back at square one every time I want to do something non-trivial. Looking forward to giving this a shot.

fatal flaw: written in ruby