HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
sharkdp
fd
Rust2017–2026
sharkdp / fd

fd

A simple, fast and user-friendly alternative to 'find'

77Distinct people
89Mentions
1Explicit recommenders
45.1KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A simple, fast and user-friendly alternative to 'find'

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

Been using ripgrep for a while now, I love it. One other Rust tool people might find useful is fd (https://github.com/sharkdp/fd) which is similar to find.

VohuMana used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 6:01:32 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year89 dated mentions

Observed mentions: 2017-06-08 08:04:19 UTC to 2026-08-28 16:56:03 UTC.

0510152017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 5 mentions; 4 submissions, 1 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 9 mentions; 0 submissions, 9 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 9 mentions; 1 submissions, 8 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 11 mentions; 1 submissions, 10 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 13 mentions; 0 submissions, 13 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 11 mentions; 1 submissions, 10 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 10 mentions; 1 submissions, 9 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 10 mentions; 1 submissions, 9 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC541
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC909
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC918
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC11110
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC13013
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC11110
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC707
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC1019
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC1019
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC404

What Hacker News says

10 sources
Perhaps interesting (for some) to note that hyperfine is from the same author as at least a few other "ne{w,xt} generation" command line tools (that could maybe be seen as part of "rewrite it in Rust", but I don't want to paint the author with a brush they disagree with!!): fd (find alternative; https://github.com/sharkdp/fd), bat ("supercharged version of the cat command"; https://github.com/sharkdp/bat), and hexyl (hex viewer; https://github.com/sharkdp/hexyl). (And certainly others I've missed!) Pointing this out because I myself appreciate comments that do this. For myself, `fd` is the one most incorporated into my own "toolbox" -- used it this morning prior to seeing this thread on hyperfine! So, thanks for all that, sharkdp if you're reading! Ok, end OT-ness.
In Hyperfine: A command-line benchmarking tool
> PowerShell has up-front required prerequisites that you can declare Anyone who's written more than a few scripts for others will have learned to do something like this at the start: declare -a reqs reqs+=(foo bar baz) missing=0 for r in "${reqs[@]}"; do if (! command -v "$r" &>/dev/null); then echo "${r} is required, please install it" missing=1 fi done if [ $missing -gt 0 ]; then exit 1 fi > Your script is very bravely trying to parse output that includes many different protocols, including: tcp, tcp6, udp, udp6, and unix domain sockets They probably didn't know you could specify a type. Mine only displays TCP4. > Now imagine putting your script side-by-side with the PowerShell script, and giving it to people to read. I'm gonna gatekeep here. If you don't know
Read the rest
what that script would do, you have no business administering Linux for pay. I'm not saying that in a "GTFO noob" way, but in a "maybe you should know how to use your job's tools before people depend on you to do so." None of that script is using exotic syntax. > Note that you had to use 'awk', which is a parser, and then three uses of 'grep' -- a regular expression language, which is also a kind of parsing. They _chose_ to. You _can_ do it all with awk (see my example in a separate post). > Literally in every discussion about PowerShell there's some Linux person who's only ever used bash complaining that PS syntax is "weird" or "hard to read". What are they talking about!? It's half the complexity for the same functionality, reads like English, and doesn't need write-only hieroglyphics for parameters. And yet somehow, bash and its kin continue to absolutely dominate usage. There is a reason that tools like ripgrep [0] are beloved and readily accepted: they don't require much in the way of learning new syntax; they just do the same job, but faster. You can load your local machine up with all kinds of newer, friendlier tools like fd [1], fzf[2], etc. – I definitely love fzf to death. But you'd better know how to get along without them, because when you're ssh'd onto a server, or god forbid, exec'd into a container built with who-knows-what, you won't have them. Actually, that last point sparked a memory: what do you do when you're trying to debug a container and it doesn't have things like `ps` available? You iterate through the `/proc` filesystem, because _everything is a file._ THAT is why the *nix way exists, is wonderful, and is unlikely to ever change. There is always a way to get the information you need, even if it's more painful. [0]: https://github.com/BurntSushi/ripgrep [1]: https://github.com/sharkdp/fd [2]: https://github.com/junegunn/fzf
In Techniques I use to create a great user experience for shell scripts
Disagree all you want, you still shouldn't be surprised people aren't expecting this fd: https://github.com/sharkdp/fd/issues?q=gitignore+ And I stand by it is strictly better for the __default__ to be unfiltered. This is what people expect in general. > tailored for the common use cases today. *YOUR* common usecases. Grep, sure, it is rare that I want to grep a binary file. But I do want to grep configs and secrets. I do want to find binaries all the time. There are many different ways to program and expecting everyone to program like you or even remotely like you is naive. There's so many things under the sun. Failure analysis is critical when designing anything. So let me rephrase Which do you think is a better mode of failure? 1) Not finding files you are expecting to find 2) Finding more files than you expect to find Or for
Read the rest
ripgrep, grepping fewer files than you expect to vs grepping more files than you expect to. It is very hard to argue for one considering we have regex to filter which files we want... not to mention pipes and all sorts of common tools including the tools themselves.
In The Modern CLI Renaissance
> fd - find alternative > rg - ripgrep (grep) NOTE OF WARNING: BY DEFAULT these ignores anything included in your `.gitignore` folder. So if you think it is a straight find replacement, you'll likely be surprised. fd discussion here[0] Just make sure that when recommending people these tools that this is clear because if they don't read the docs (lol who does) they'll miss this part. This is a pet peeve of mine. I wish the people that make these replacement coreutils (and others) would leave the defaults as very similar to the original tool. I do really like the new functionalities but if you market it as "an alternative" ("It is a simple, fast and user-friendly alternative to find") then they should respect the defaults of the original because it reduces new user surprise. I mean aliases exist... So it is better to have in your ~/
Read the rest
.${SHELL##*/}rc file to have `alias fd='fd --ignore'` than `alias fd='fd --no-ignore'`. Side note/pro tip: use `\command` if you want to use an unaliased version. An example of this is that I have `alias grep='grep --color=always --no-messages --binary-files=without-match` but this can sometimes be problematic because the color option can change the character representation so if you pipe this into `curl` you will get errors. This is not the case in all piping, but it is a shocking and confusing experience when you first encounter it. You can validate this by `echo "Hello world" | \grep --color=always "Hello" | hexdump` and then `!!:s^always^never` [0] https://github.com/sharkdp/fd/issues/612
In Eza: A modern, maintained replacement for ls
I tried this and a handful of alternatives a while back, but would often get frustrated because they’d jump to something different than what I intended or were missing some directory I wanted. Eventually I came up with an alternative using fd¹ and fzf². I have a variant of this in my .zshrc: function n { cd "$(fd . "${HOME}" --type d --color never | fzf --select-1 --query "${*}")" ls } Call it with `n` and get an interactive fuzzy search for your directories. If you do `n <argument>`, it’ll start the find with `<argument>` already filled in (and if there’s only one match, jump to it directly). The `ls` is optional but I find that I like having the contents visible as soon as I change directories. In my personal setup I’m also including iCloud Drive while excluding the rest of the Library directory³ as that is too noisy. I hav
Read the rest
e a separate `nl` function which searches just inside `~/Library` for when I need it, as well as other specialised `n<char>` functions that search inside specific places that I use frequently. ¹ https://github.com/sharkdp/fd ² https://github.com/junegunn/fzf ³ Change the fd command to: fd . "${HOME}" "${HOME}/Library/Mobile Documents/com~apple~CloudDocs" --exclude '/Library/' --type d --color never
In Z – Jump around

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.