fd: A simple, fast and user-friendly alternative to 'find'
306 comments
·March 19, 2025snide
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.
tandr
Same Astral as `uv` makers? Geez, these guys are specializing on "making things go zoom-zoom"!
kiney
semi related: how does astral actually make money to pay the devs?
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)
kstrauser
Hard agree about zellij. I used screen, then tmux, for years. Zellij feels "right" for me in a way those never quite did. It's brilliant.
aaplok
What differences between Zellij and tmux do you see as game changers?
wanderingmind
Never knew about Terminal Trove.looks like an awesome place that collects a lot of useful terminal tools. This website must be a separate HN posting.
joshbaptiste
Only default of Zellij I can't stand is ctrl-q exits the whole instance
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
numbers
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.
makapuf
Completely in line to put some money where my mind is regarding opensource (just sponsored framasoft from another thread).
Do keep in mind how much how trillonaire/billionaire companies sponsor the free software they use while doing so.
synergy20
bat, fd, rg for me
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/
johnisgood
koji would be fine, but I want to stick to 67 column width and I could not do it with this, I think? I use git-cola, instead.
alkh
yeah, that's a problem for me as well. I end up doing koji->gitlint->git commit --amend --edit if there are any width issues
tmtvl
Would be nice if you could filter based on license. I really want to avoid non-(A)GPL tools where possible.
imoreno
Instead of koji, I use `aider --commit`
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.
hnlmorg
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.
burntsushi
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`.
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.
hnlmorg
> As the author of ripgrep, I find this unconvincing personally. Have you ever tried to use `sed` with its `-i` flag?
I have. But that’s one inconsistency and an edge case I rarely need to worry about.
Plus we are talking about grep here, not sed. I created my own “sed” because I got fed up with dealing different implementations of existing seds. If others use it or don’t use it then that’s their choice, not mine.
> 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.
UNIX tools are a mess too. My point wasn’t that their flags are more sane than modern tools. It’s that I’ve already committed to memory the flags for the tools I use daily.
> Each one cost me about a Sunday and a half, but they've been paying rewards ever since
I spend my free time writing open source tools that solve problems I run into (like fixing the limitations with existing UNIX shells, and presently writing a new terminal emulator with a ton of features existing ones neglect). So I don’t have time to learn new tools to solve problems I don’t have.
Edit:
I just want add to my previous comment that some of my open source tools do make use of your fantastic Go libraries, such as the Unicode width library.
So I’ve really valued your contributions to open source even though I don’t personally use ripgrep specifically.
ziml77
I’m happy you gave ripgrep an option to perform replacements so I don’t have to worry about sed and its lack of a standard way to change files in-place. I realize on my Mac I could install GNU sed, but if I’m going to install an extra utility anyway, why not go with something that is overall nicer?
thiht
sed has to be one of the worst POSIX tools. It sounds simple enough, but everytime I reach for sed it doesn't do what I want, either because it doesn't align with how I do things, or because it just doesn't support doing it (especially multiline replacements for example).
I've switched to sd[1] because it basically just works as I expect every time.
ForTheKidz
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.)
sweeter
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.
renewiltord
It's actually because they stayed compatible that the problem arises: fd and find -type mean the same but this user wants them to be different.
Overall, I use AI shell completion so it's much smoother.
hnlmorg
I’ve been thinking of adding AI completion into my CLI tools but not really sure how to implement it in a non-intrusive way. So I’ve got a few questions, if you don’t mind sharing:
What’s the workflow like for AI shell completion?
How does it know which flag to complete for you? Do you write a description in native language (eg English) and it completes the entire command line? Or is it more one flag at a time?
derriz
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.
thayne
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.
laktak
I used sql instead of flags to make it easier to remember - see https://github.com/laktak/zfind
terminaltrove
if you want to try fd, bat, numbat, hexyl and hyperfine, you can install them quickly and see screenshots of them below on Terminal Trove:
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.
andy_xor_andrew
cool site, have you considered using asciicinema instead of screenshots? Seems like the perfect tool for what you're trying to do
archon810
I clicked on several utils on the site, and they all had GIFs of the demos.
I think terminaltrove takes these from the projects themselves instead of creating them on their own.
nchmy
I look forward to exploring the tools some more. Though, I install everything these days via mise (which you list as well).
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
d0mine
Perhaps something like https://github.com/xtermjs/xterm.js can be used to show interactive sessions for TUI apps.
jwrallie
Nice suggestions, I’ll be definitely trying numbat and hyperfine (I already use fd daily).
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.
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.
TylerE
Confession; the only way I’ve ever actually used find is just a tree walker piping to grep to actually find whatever.
mat_b
[dead]
quinncom
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?
orlp
I would suggest
fd -t f . cache -X rm --
This ensures even if you have filenames starting with - they won't be interpreted as options for rm. For even more sanity of mind you may want to turn on -a for absolute paths, although I don't see an example right now where using relative paths would go wrong.
null
scorcessse
[flagged]
lolinder
> This is how good things turn to crap: people want to be accommodated rather than have to learn something new.
Funny, this sounds more like an explanation for how we get stuck with crap and aren't able to move on to better interfaces.
EMIRELADERO
And here I was thinking the RTFM days were over...
TylerE
Have you ever tried to actually learn something from a manpage?
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.
syklemil
> 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`
graynk
it tangentially matters, because cargo is so good that I use it instead of a package manager for all these fancy rust tools
eulers_secret
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.
thesuperbigfrog
>> 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."
uutils is being adopted in Ubuntu 25.10:
rednafi
I welcome this wholeheartedly. If Ubuntu adopts that and it doesn’t need me to deal with any incompatibility, then it’s a win-win for everyone.
d0mine
Does it mean unless your ip is considered “friendly“, you can’t use basic computer utils? Gnu utils seem more accessible (more freedom long term).
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.
thayne
> there's not much reason to switch
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
theragra
By the way, FAR manager was ported to Linux quite a long time ago, but I forgot about it.
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.
BeetleB
I use FAR on Windows. Midnight Commander serves me well in Linux - not sure I'd prefer FAR manager. But yes, FAR is closer to Norton than mc.
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.
nrvn
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.
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.
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.
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.
Joe_Cool
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)
ajolly
You should check out void tools search everything!
eredengrin
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.
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`.
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.
rtfd
[dead]
jpeeler
Same, I never remember them either. However, I use a shell (fish) that has decent command history autocompletion that helps a lot for such things.
I wish the flags between ripgrep and fd lined up as I think that's what confuses me (can't remember now haha).
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.
timewizard
You're just using the unix pipeline as it was intended. I always prefer this over having to remember a bunch of obscure command line switches.
VTimofeenko
Check out `curl cht.sh/${utility_name}`. It will print a short help page with some common examples
hnlmorg
Shameless plug:
Or just press F1 if you use my shell.
https://murex.rocks/user-guide/interactive-shell.html#autoco...
helsinki
Hm, I feel like I have roughly the exact same functionality with zsh and some various plugins, including the meta editing experience shown in your demo video ($EDITOR) via Kitty and/or WezTerm.
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
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-...)
yread
Err no? grep searches contents and op is looking in filenames
forinti
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.
null
ltbarcly3
nope, not remotely the same thing
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.
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.
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).
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.
alwillis
When I setup a new machine, the first two apps I install are bat and eza.
Both are “must haves” as far as I’m concerned.
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.
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.
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.
kiwijamo
Both commands work in either I believe. I've been using both since my FreeBSD days and now I use Debian Linux with no change.
mitsu_at
Reminded of this xkcd :P https://xkcd.com/1168/
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`
bbkane
I've never internalized this, so I usually stick to using absolute paths...
Not a solution for all problems, but it works for me most of the time.
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
porridgeraisin
> tar
I remember only two flags for tar. That's it.
tar -x
tar -c
I use it like so:
tar -c src | gzip > src.tar.gz
curl https://source.code/src.tar.gz | gunzip | tar -x
The core operations taking up only this much headspace leaves the door open to slowly start to retain all its other useful options. For example, -v, which means verbose almost everywhere, thankfully means verbose here too, so I add that when I want verbosity.
Similarly, I find it easy to retain -l which lists the contents. I do this quite often for stuff from the internet -- I don't like it when I untargz in ~/Downloads and it untargz's it in the same directory instead of doing everything inside a parent directory (preferably with the same name as the archive)
Bonus: separating out the gzip like this makes it easy to remember how to use zstd if you want to, just pipe to zstd instead! "Unix philosophy" and all that.
I agree with you about `ln`, I can never seem to remember if it's source or target that comes first.
pimlottc
For folks on macOS, you can also use "mdfind" as a command-line interface for macOS Spotlight search
spudlyo
Considering how many as many CPU cycles and iops that Spotlight robs from you on a regular basis, you might as well get some use out of it.
kstrauser
I never remember what it's called, so I have `alias locate 'mdfind -name'` in my shell setup.
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.
meisel
Personally I prefer bfs (https://github.com/tavianator/bfs) because it does a breadth-first search
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.