fd: A simple, fast and user-friendly alternative to 'find'
123 comments
·March 19, 2025snide
terminaltrove
in complete agreement, with tools like fd getting more visibility!
we sponsored fd's development a while back and we occasionally sponsor terminal tool authors from time to time at Terminal Trove where we have more tools in the trove. (0)
we're currently sponsoring zellij which I encourage you to check out and sponsor! (1)
seafoamteal
bat, fd, and hyperfine are all by the same person??? That's incredible, I love all of these utilities.
jessekv
Seems like David Peter works at Astral now, as does Andrew Gallant (ripgrep).
It's a dream team for rust cli tools over there.
1-more
I owe hours of my life to Andrew Gallant aka BurntSushi's xsv. Nothing else tries to handle splitting long files into N-row chunks [1]. I was using the command line utility, but that's his wrapper around his rust-csv library. So if you need CSV parsing in rust, I strongly recommend this library.
[1] rows included linebreaks so your standard sed/head/tail/something-from-coreutils approach would not work.
danso
Was just going to say, the fd,bat author reminds me of burntsushi (xsv, rg), in terms of the massive benefit they've added to the *nix command-line ecosystem.
jhbadger
I'm glad you identified the author -- I'm a big fd and bat fan but didn't know they were created by the same person. I'll have to check out his other tools.
mgrandl
You should also check out numbat. It's insanely good.
stared
Link for anyone interested: https://github.com/sharkdp
alkh
Imo, everyone should check https://terminaltrove.com/ from time to time. There, I have found easy replacements to commonly used tools:
find -> fd, time(for runtime comparison) -> hyperfine, grep->ripgrep, asciinema + converting to .gif -> t-rec[1], manually creating convertional commits -> koji[2], etc.
[1]https://terminaltrove.com/t-rec/ [2]https://terminaltrove.com/koji/
enricozb
I wish fd and rg would align some of their flags. For example, both fd and rg have a --type, but for fd it means file/directory/symlink etc. For rg it means the file MIME type. Another example is that fd has an --extension flag, and rg doesn't.
Since I believe the correlation of usage of these tools is high, I think they could benefit from having similarly named flags.
travisgriggs
I’ll have to try this out. I admit that most of my uses of find looke like
find . | grep what_i_am_looking_for
Because I can never remember how finds arguments work. I like the integrated xargs like behavior as well.
One thing I did not see in there was how fd handles symlink directory traversal? Searched the whole readme for it, and only found options to match on symlinks or not.
layer8
In that case, you might as well just use grep -r, or its alias rgrep. And then remember that it supports --include=GLOB, --exclude=GLOB, and --exclude-dir=GLOB.
(That’s GNU Grep, just to be clear: https://www.gnu.org/software/grep/manual/grep.html#File-and-...)
VTimofeenko
Check out `curl cht.sh/${utility_name}`. It will print a short help page with some common examples
bee_rider
I’m finding that I use locate more and more for this sort of thing. Of course, it produces a lot more output, because it looks at the whole system. But, it is still much faster than find because it runs on some kind of index or something, and it is easy enough to grep out the directory I’m interested in, if needed.
gcmeplz
locate is nice, but I think that on most distros its index is only updated once/day (unless you adjust the cron job that updates it more often). Most of the times I'm trying to find something, I haven't modified it recently, but it can definitely lead you astray.
silisili
One can just run 'sudo updatedb' to refresh it. Super fast if it's already on a schedule. I think mine is set to update every system update, so I just have a habit of running that before I use locate each time.
diziet_sma
fd --help | rg link -C 10
xiphias2
That's basically rg
kstrauser
I use the heck out of fd daily and it’s in my standard installation on new machines. I’ve used find for years and it’s great in its own ways, but convenient ergonomics isn’t among them.
I’m 100% on board with this recent-ish trend toward new replacement utilities that may or may not retain all of the flexibility of the originals but are vastly easier to use for common cases.
ilyagr
I got used to https://github.com/tavianator/bfs instead. Breath-first ordering is nice.
Interestingly, the author is listed as one of the maintainers of `fd` as well.
pimlottc
For folks on macOS, you can also use "mdfind" as a command-line interface for macOS Spotlight search
rednafi
One reason I haven’t picked up any of these newfangled Rust tools like bat, exa, or fd is that I can barely remember the options for the originals.
For me, anything that isn’t a drop-in replacement for the OG tools isn’t worth the friction. I use ripgrep inside VS Code but vanilla grep on the command line because of years of muscle memory.
That said, I don’t care what language a tool is written in as long as it works. One of my favorite Unix tools is GNU Stow, and it’s written in Perl. Even if these Rust tools were drop-in replacements, I probably wouldn’t bother installing them manually. As a user, the speed improvements and memory safety don’t really matter to me.
There are other languages, like Go, where memory safety is guaranteed as well, and Go’s performance is more than adequate for tooling—with the added benefit of getting more engagement from the community. So I’m not entirely convinced by this “Rust is the savior” narrative.
That said, if macOS or Ubuntu decided to hot-swap the OG tools with Rust alternatives that behave exactly like their predecessors, I probably wouldn’t complain—as long as it doesn’t disrupt my workflow.
jhbadger
>One reason I haven’t picked up any of these newfangled Rust tools like bat, exa, or fd is that I can barely remember the options for the originals.
But that's exactly the reason to use the newer tools -- they just make more sense -- especially fd over find. I've been using UNIX for over thirty years and find just never clicked with me.
johnisgood
> One of my favorite Unix tools is GNU Stow
What about https://zolk3ri.name/cgit/zpkg/? A lot of improvements have been done behind the scenes apparently (rollback, proper states, atomicity, etc.), but I am not sure when he is willing to publish.
I personally use it as-is when I am compiling stuff myself and the ZPG_DST is ~/.local/. It works well for keeping track of programs that I compile and build myself.
whompyjaw
It absolutely does not matter what language this tool is written in. That goes for any tool. If it’s better, use it. In this case, fd is far superior to “find” in almost every way. Sane defaults, wayyy faster, easy options (just use cht.sh if you can’t remember) To me, there is no reason to ever use “find”. If I’m on a new system, I just install fd and carry on.
BeetleB
If you're already proficient with grep, find, etc - there's not much reason to switch. As I said elsewhere:
I never managed to use find because I always had to look up command line arguments. I would always find a different way to solve my problem (e.g. Midnight Commander).
I use fd all the time.
A better interface makes a big difference.
mellosouls
For anything I can't remember, I just use at the command line:
? toolname <option>
Eg
? git branch
which gives me common examples of git branch
It aliases to tldr which is normally up to date with new tools.
See also cheat.sh etc.
I understand the point about muscle memory but I think that was more of a concern in the days before we had it easy with instant internet answers and now LLMs (eg GitHub copilot command line) doing our boring thinking for us.
meisel
Personally I prefer bfs (https://github.com/tavianator/bfs) because it does a breadth-first search
tavianator
Someday I will get that functionality into fd :)
Babkock
One of those essential tools, that's not ever included with GNU/Linux by default, but I always install almost immediately along with ripgrep, bat, fzf, htop.
kristopolous
try ugrep https://github.com/Genivia/ugrep ... if you don't switch over in a day, I'll eat my shoe.
It supports all the common grep options and you can split view in the -Q mode and it is smart enough to open your $editor at the line number it's talking about.
Try it, this is the workflow I've been waiting for.
Also lf. https://github.com/gokcehan/lf You've been wanting this for years as well.
No really. Just scroll: https://github.com/gokcehan/lf/wiki/Integrations ... https://github.com/chmouel/zsh-select-with-lf these things will change your life. I promise.
kstrauser
Whoa! Thankgs for mentioning lf. That's beautiful!
creeble
For the sake of Ubuntu users, it’s ‘apt install fd-find’. You’ll need an alias fd=fdfind too.
meonkeys
Agreed! Curious what your base OS is. Mine has been Ubuntu LTS for years, but now I find myself installing so many custom tools like these I'm thinking I might want to move to NixOS or Gentoo or something like that instead. I just don't want to lose out on stability and great hardware support.
carlhjerpe
Hey!
I would recommend trying home-manager, or just plain nix profiles before going all-in on NixOS, it's very easy to add Nix on top of any Linux (and MacOS to an extent).
This way you still have your tried and true base system and you can manage things somewhat like you're used to (and use venv and whatever bullshit package manager everyone invents), a lot of common tools will work poorly on NixOS (venv, npm...)and while they have Nix alternatives that are "better" it's DIFFERENT.
I run NixOS on desktop and laptop but I wouldn't recommend starting with it, you can benefit from all packages on any distro by just installing Nix.
Also home-manager adoption can be incremental.
ADHD end note: home-manager is perfect for CLI tools installation and config. You must unconfigure "secure path" in sudo though otherwise your CLI tools don't work with sudo
thibran
I would add 'ouch' to the list. It allows easy compression/de-compression.
drcongo
And procs - https://github.com/dalance/procs
actinium226
Is anyone else bothered by the fact that by default it ignores a lot of folders? I use `find` when I'm like 'I just want to know where on my system this is, wherever it might be'
I know fd has options to not ignore things, but I can never remember them, so I just go back to find because I know it'll search everything.
kstrauser
That’s a feature, and one of the reasons I prefer it. When I want to find a file in a git repo, say, there’s no need looking inside .git most of the time. Sometimes there is: if I don’t remember `fd -u`, there’s good old find there for me. But that’s almost never what I want to do, so fd’s defaults are sensible for me.
pantsforbirds
I actually prefer it. It's very similar to ripgrep's default search. I do occasionally want to find something in a .gitignore, or other hidden directory, but I don't mind taking the time to `rg/fd --help` and add the flag to include hidden directories.
jandrese
Same thing that drives me crazy with Windows built-in file search. The Windows one ignores AppData, which is where everything gets stashed these days.
burntsushi
ripgrep has the same default behavior.
You just want `fd -u`. Or in ripgrep's case, `rg -uuu`.
`fd`, I believe, got `-u` from ripgrep. And I can say that ripgrep got its `-u` from `ag`.
agumonkey
As much as i love new rust cli tools, `fd` ended up in the same bag as tar and ln.. I can never retain how to use it. I don't blame anybody .. I'm just witness that I always have to re-read the man from scratch to get anything done. And I'm not a gnu find lover.. with all its idiosyncracies.. somehow it registers better.
bee_rider
For tar, I just remember tar czvf and tar xzvf.
Of course, then we get the question, ok, why not use a program that just provides those options? But, I think all the extra functionality of tar is nice to have sitting off there in the background; I’d have to look it up if I actually wanted to use it, but it is all there in the documentation, and nicely compatible with the files produced by my memorized commands.
sitkack
Fully laden Gnu tar or BSD tar?
bee_rider
I guess GNU most likely. On my system, it’s just Ubuntu, and on the server side, it is, I guess, whatever the administrator installed, haha.
mitsu_at
Reminded of this xkcd :P https://xkcd.com/1168/
nottorp
> As much as i love new rust cli tools
Why would you love them just because they're in rust?
I'd like to praise the author of this fd for not having "Rust" all over the web page or in the HN link, actually.
The Rust inquisition would get far less pushback if instead of threatening people that god will kill a kitten every time you use a non-kosher programming language, they'd promote software that improves (even opinionated improves, like this fd) on existing tools instead of having its main feature "but it's written in Rust!".
stouset
That is literally what people are doing. “Written in Rust” has become a pretty convenient shorthand for “this was written by someone who cares deeply about quality, and you can guess that it will be extremely fast, relatively free of bugs, and use as many cores as you want to throw at it”.
While you’re out here complaining, the Rust community has built a truly impressive array of improved, human-focused command line tools (rg, bat, fd, hyperfine, delta, eza, and on and on) and a bunch of best-in-class libraries for building tools (regex comes to mind).
dietr1ch
The ecosystem enables focusing on the task at hand. It's great that you don't need to get side-tracked at every single step. There's many high quality libraries.
BoingBoomTschak
While mostly true, there's a large problem with lots of these Rust CLI tools (and I use some of them, don't misunderstand me): they often discard the UNIX philosophy in favour of newbie friendliness and glitter.
For example, ripgrep shouldn't merge find and grep (actually, I use a personal wrapper around `find ... -exec grep ... {} +` because my only beef with this is that find's syntax to exclude stuff is horrible, https://git.sr.ht/~q3cpma/scripts/tree/master/item/find_grep). Or you see something like https://github.com/shssoichiro/oxipng/issues/629 because people don't even know how to use xargs...
Feels like if someone did a RIIR on ImageMagick, it'd be able to talk with Instagram and Flickr by itself or process RAW files like Darktable. Would probably have some kind of tagging system too.
thiht
> Why would you love them just because they're in rust?
That's not it. People love the new rust tools because they're great tools with sane defaults. They happen to be written in Rust most of the time and that's it so people use this to describe them.
chrisweekly
That's a bit extreme. I'm not who you replied to, but IME, things written in rust tend to be fast and sane. All else equal, "written in rust" is a positive signal to me.
agumonkey
performance for a start
especially in the case of fd, it's way faster than gnu find
sorry if that annoys people, but a rust tool starts with a high trust in my mind that it will fly
ps: to show i'm not in full fanboy mode, i'm often surprised that fzf, brilliant and performant tool, is written in go, but i know it's not rust :)
alp1n3_eth
Surprisingly, Go is great for CLI tooling. It may not have the insane speed that carefully planned and written Rust does, but it's very easy to write and be performant without even needing to go to great lengths to optimize it.
I generally say that anything under 500ms is good for commands that aren't crunching data, and even Python CLI tools can come in under that number without too much effort.
nottorp
> especially in the case of fd, it's way faster than gnu find
... also the only tool written in Rust that made it to HN lately that does not scream "I'm written in Rust!" everywhere :)
It also aims to improve on gnu find, not to reimplement it because it's in a non approved language.
It's what the Rust evangelists aren't.
umanwizard
If you’re having trouble remembering the order of arguments to ln, remember that it’s the same way around as cp. Worked for me.
That is, if before there is something at /some/path but not /another/path , after running
ln /some/path /another/path
stouset
The one that always trips me up is that `ln` is “dumb” about how it handles the first argument.
If the first argument isn’t an absolute path, it must be relative to the second argument, and not to pwd.
ln ./foo ./bar/baz
This is totally backwards from how other utilities behave. Which is completely understandable if you know what it’s doing under the hood. But it is counterintuitive and surprising.
tavianator
At least with GNU coreutils, you can use `-r`/`--relative`
mturmon
This is what made the “ln” argument order click for me as well.
Another piece of this parallel is that (with cp and mv) you can omit naming the destination file - you often just name the directory:
cp /other/dir/foo.txt .
ln -s /other/dir/foo.txt
agumonkey
thanks, i still need to ignore the fact that the link on the right points to the left then
Big sharkdp fan. Ty you for making awesome software that i use DAILY.
bat, fd, hexyl, hyperfine
I'm going to take this moment to remind all of you well-paid engineers that if we each spread $10 a month sponsoring talented software makers like sharkdp the Internet would be a better place.
So many great little tools out there and we should try to support an ecosystem for them.