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.
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)
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.
I wish there was an easy way to find people to sponsor whose repos I use (not depend on because every project I use multiplies the same dependencies) but there are tools I use daily that aren't dependencies in my project like wezterm or atuin.
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.
To be honest, this is one of the reasons I usually stick with POSIX tools, I’m too old and too lazy to want to learn a whole new set of flags for a whole new set of tools that are very close to but not quite the same as what’s already part of my muscle memory now.
Not taking anything away from the tools that have been written. Just for me, the pain of learning a new tool is greater than the convenience I’d gain from using it.
As the author of ripgrep, I find this unconvincing personally. Have you ever tried to use `sed` with its `-i` flag?
That's because `-i`, while incredibly useful, is not POSIX. So when you say "POSIX tools," what you actually probably mean is, "superset of POSIX tools."
There is some agreement among the same tools as what the options in the superset actually mean, but not always, as is the case with `sed`.
As for whether flags are consistent across different tools, well that's a total crapshoot. `find` uses `-L` for following symlinks while `grep` uses `-R`. Ironically, both `fd` and ripgrep use `-L`, so they are more consistent than the relevant superset-plus-POSIX tooling on at least that front.
To be clear, I mean this somewhat narrowly. Namely
> I’m too old and too lazy
I totally get that. I have a bunch of things I kinda want to learn and do, but just not enough time in the day. But I do still try to make time for these things. I did it for `tmux` (previously, `screen`) and `zsh` (previously, `bash`) and I am very happy I did. Each one cost me about a Sunday and a half, but they've been paying rewards ever since.
ripgrep solves a really annoying part of the unix toolbox: inconsistency in how to correctly search a bunch of files for a string. Are you supposed to `find -name -exec`? Or are you supposed to `find -name | xargs -n 1`? Oh, but files can have spaces, so you might try `find -name -print0 | xargs`, but careful—`-print0` is not POSIX and you won't find it on some unixen! (let's not even discuss locate vs slocate vs mlocate.... ugh! Files are worse than everything but all the other options.)
this is what tab completion and tldr is for. 99% of use cases are well covered and clear by the name of the flag, and a good CLI tool will make that easy to understand. A quick example and self-explanatory flags with tab-completion is all you need. Then if you ever have a more complicated use case, you can grep through the man page.
its legit as simple as "fd -e png -x optimize-png {}" the only thing I dont like about fd is that for some reason it kind of forces you to do 'fd . Downloads' if you just want everything in "Downloads" which equates to 'fd {pattern} Dir1 dir2" I wish you could omit the pattern sometimes.
Yeah this annoys me even though I'm a daily user of both fd and rg. What makes it more confusing is that many of the flags DO align - or partially align.
For example, I'm used to glob patterns but the glob flag (-g) works differently in fd and rg. I think that fd's -g flag does not use "full-path" globbing while rg's -g does (or the other way around). To get fd to use rg style globs, it also needs the -p flag, which rg also recognizes but it has a completely different meaning for rg and has nothing to do with how globbing/filename matching works.
I guess I'm used to the warts at this stage, like I had gotten used to the warts on find and grep all those years ago.
Difficult or impossible to fix these inconsistencies at this stage without breaking backward compatibility.
It's a tricky balance. To use your --type example, it isn't consistent with rg, but it is mostly consistent with find. And fd'a --type option is much more useful for fd than an equivalent would be for rg. It doesn't make a lot of sense to filter the files to grep to directories, or sockets, but that is useful if you are searching for file names, or even just all files of a certain type. Conversely, rg's --type option isn't quite as useful for fd, because fd is already matching a pattern against the file name, so you can easily just add the appropriate extension to your search pattern. Or use the --exyension flag.
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.
>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.
fd is probably better for most tasks, but sometimes it seems more cumbersome than find. E.g., to delete all files inside a cache directory, this is the simplest syntax I could find:
fd -t f -X rm {} \; ^ cache
Which makes me really nervous, so usually I fall back to using find:
find cache -type f -delete
Maybe this is foolproof for me only because I’ve been using find for decades. Is there a version of this for fd that inspires more confidence?
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.
> It absolutely does not matter what language this tool is written in. That goes for any tool.
Eh, there are a lot of tools where it actually does kind of matter. I suspect for a lot of invocations of tools like `fd` and `rg`, they'll be done before an equivalent written in java has even had its JVM spin fully up.
There's _tons_ of Java software, but it somehow never managed to make a dent in the CLI space.
> To me, there is no reason to ever use “find”. If I’m on a new system, I just install fd and carry on.
I guess I should finally have a look at how to replace my `find $path -name "*.$ext" -exec nvim {} +` habit … turns out it's `fd -e $ext -X "nvim" "" $path`
Another reason to at least learn the default tooling is that often I find myself SSHing to another machine which has only the barest of default packages installed (often busybox, sometimes just a stripped-down docker container).
If I didn't know how to use "find" and "grep" (though I prefer rg) then I'd be at a disadvantage in these situations. Also command-line git.
It's why I learned to use Vim well, though I daily Emacs.
>> For me, anything that isn’t a drop-in replacement for the OG tools isn’t worth the friction.
"The uutils project reimplements ubiquitous command line utilities in Rust. Our goal is to modernize the utils, while retaining full compatibility with the existing utilities. We are planning to replace all essential Linux tools."
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).
There are a few reasons you might still want to switch. In fd'a case:
- It respects .gitignore files (as well as similar .fdignore files that aren't git specific), which can help you find what you care about without a lot of noise, or having to pass a lot of exclude rules to find
- it can search in parallel, which can significantly reduce latency when searching large directories.
However, there are also reasons you might want to keep using find:
- fd can't do everything find can. fd is intended to replace the most common use cases with a simpler interface, but there are many less common cases that require finds greater flexibility. In fact, I still use find sometimes because of this.
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.
It resonates with me wrt muscle memory and ubiquity of “standard tools” that come pre-installed in majority of *nix distros including macos.
But there is a big BUT! Lately I have to use grep/find huge nested dirs and found rg to be an order of magnitude faster. Had to get myself comfortable with retraining the muscle memory. Worth the effort.
Some of these new shiny tools are meh for my taste. Delta for instance. Or helix the editor. But it is personal. Overall I love the competition. It seems like industry once full of innovators and tinkerers is lacking some shake up.
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.
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.
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.
I completely dumped the windows search and only use voidtool's Everything when I am on a Windows box.
It can search multiple indexed NTFS drives in miliseconds. Indexing is usually a few seconds since it works directly on the NTFS structures.
(and it integrates with Total Commander)
Same, this is why I haven't fully converted to lots of these newer tools. If I have to remember a bunch of special flags to make them look at the files I need them to, their advantage is lost. I'm better off using the originals and solidifying those flags in my muscle memory since at least those tools will be on any system I use. I do use ripgrep on occasion but not very often.
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.
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.
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.
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.
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.
Not the same thing, but thank you. I've been using "find . -type f -exec grep -i {} /dev/null \;" without looking for a better solution and here it is.
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.
Readit News
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.
It's a dream team for rust cli tools over there.
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)
https://terminaltrove.com/ (0)
https://github.com/zellij-org/zellij (1)
Do keep in mind how much how trillonaire/billionaire companies sponsor the free software they use while doing so.
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/
Since I believe the correlation of usage of these tools is high, I think they could benefit from having similarly named flags.
Not taking anything away from the tools that have been written. Just for me, the pain of learning a new tool is greater than the convenience I’d gain from using it.
That's because `-i`, while incredibly useful, is not POSIX. So when you say "POSIX tools," what you actually probably mean is, "superset of POSIX tools."
There is some agreement among the same tools as what the options in the superset actually mean, but not always, as is the case with `sed`.
Compare, for example, what `man grep` says on your system with the POSIX definition: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/g...
As for whether flags are consistent across different tools, well that's a total crapshoot. `find` uses `-L` for following symlinks while `grep` uses `-R`. Ironically, both `fd` and ripgrep use `-L`, so they are more consistent than the relevant superset-plus-POSIX tooling on at least that front.
To be clear, I mean this somewhat narrowly. Namely
> I’m too old and too lazy
I totally get that. I have a bunch of things I kinda want to learn and do, but just not enough time in the day. But I do still try to make time for these things. I did it for `tmux` (previously, `screen`) and `zsh` (previously, `bash`) and I am very happy I did. Each one cost me about a Sunday and a half, but they've been paying rewards ever since.
its legit as simple as "fd -e png -x optimize-png {}" the only thing I dont like about fd is that for some reason it kind of forces you to do 'fd . Downloads' if you just want everything in "Downloads" which equates to 'fd {pattern} Dir1 dir2" I wish you could omit the pattern sometimes.
Overall, I use AI shell completion so it's much smoother.
For example, I'm used to glob patterns but the glob flag (-g) works differently in fd and rg. I think that fd's -g flag does not use "full-path" globbing while rg's -g does (or the other way around). To get fd to use rg style globs, it also needs the -p flag, which rg also recognizes but it has a completely different meaning for rg and has nothing to do with how globbing/filename matching works.
I guess I'm used to the warts at this stage, like I had gotten used to the warts on find and grep all those years ago.
Difficult or impossible to fix these inconsistencies at this stage without breaking backward compatibility.
fd - https://terminaltrove.com/fd/
bat - https://terminaltrove.com/bat/
numbat - https://terminaltrove.com/numbat/
hyperfine - https://terminaltrove.com/hyperfine/
hexyl - https://terminaltrove.com/hexyl/
we make a real effort to ensure that you can install them with the ability to see the screenshots.
https://asciinema.org/
I think terminaltrove takes these from the projects themselves instead of creating them on their own.
Would be cool if you had mise commands - be it just
mise use -g fd
or for other tools that arent in their registry, how to use the backends like
mise use -g cargo:xyztool
I could see bat being useful only as the last program on a long pipe chain, but I really like xxd so I will pass on hexyl.
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.
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.
fd -t f -X rm {} \; ^ cache
Which makes me really nervous, so usually I fall back to using find:
find cache -type f -delete
Maybe this is foolproof for me only because I’ve been using find for decades. Is there a version of this for fd that inspires more confidence?
Deleted Comment
Dead Comment
Eh, there are a lot of tools where it actually does kind of matter. I suspect for a lot of invocations of tools like `fd` and `rg`, they'll be done before an equivalent written in java has even had its JVM spin fully up.
There's _tons_ of Java software, but it somehow never managed to make a dent in the CLI space.
> To me, there is no reason to ever use “find”. If I’m on a new system, I just install fd and carry on.
I guess I should finally have a look at how to replace my `find $path -name "*.$ext" -exec nvim {} +` habit … turns out it's `fd -e $ext -X "nvim" "" $path`
If I didn't know how to use "find" and "grep" (though I prefer rg) then I'd be at a disadvantage in these situations. Also command-line git.
It's why I learned to use Vim well, though I daily Emacs.
"The uutils project reimplements ubiquitous command line utilities in Rust. Our goal is to modernize the utils, while retaining full compatibility with the existing utilities. We are planning to replace all essential Linux tools."
https://uutils.github.io/
uutils is being adopted in Ubuntu 25.10:
https://www.theregister.com/2025/03/19/ubuntu_2510_rust/
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.
There are a few reasons you might still want to switch. In fd'a case:
- It respects .gitignore files (as well as similar .fdignore files that aren't git specific), which can help you find what you care about without a lot of noise, or having to pass a lot of exclude rules to find
- it can search in parallel, which can significantly reduce latency when searching large directories.
However, there are also reasons you might want to keep using find:
- fd can't do everything find can. fd is intended to replace the most common use cases with a simpler interface, but there are many less common cases that require finds greater flexibility. In fact, I still use find sometimes because of this.
- find is more likely to already be installed
Recently I remembered and installed it. Not too hard to install (although you need to use third party repos sometimes).
And then - voila - a lot of convenience for dinosaurs from Norton Commander era like myself, who cant remember cli tools syntax that well.
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.
But there is a big BUT! Lately I have to use grep/find huge nested dirs and found rg to be an order of magnitude faster. Had to get myself comfortable with retraining the muscle memory. Worth the effort.
Some of these new shiny tools are meh for my taste. Delta for instance. Or helix the editor. But it is personal. Overall I love the competition. It seems like industry once full of innovators and tinkerers is lacking some shake up.
? 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.
https://tldr.sh/
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.
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.
It can search multiple indexed NTFS drives in miliseconds. Indexing is usually a few seconds since it works directly on the NTFS structures. (and it integrates with Total Commander)
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`.
Dead Comment
I wish the flags between ripgrep and fd lined up as I think that's what confuses me (can't remember now haha).
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.
Or just press F1 if you use my shell.
https://murex.rocks/user-guide/interactive-shell.html#autoco...
(That’s GNU Grep, just to be clear: https://www.gnu.org/software/grep/manual/grep.html#File-and-...)
Deleted Comment
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.