16 ms·
A simple, fast and user-friendly alternative to ‘find’
- smoothgrammer 4y agoOne thing to remember is that these fun utils won't exist on production servers. You also don'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.
- unnouinceput 4y agoWhat is the obvious reason? Security? The guy provides sources and it took me 20 minutes to see what's doing in there. I'd definitely put this on production server, after testing intensively of course.
- butwhywhyoh 4y agoHow frequently are you and your team willing to spend that 20 minutes? Are you confident you evaluated it precisely? Are you always going to install the latest release? What do you do as the codebase grows and that 20 minutes turns into an hour?
- unnouinceput 4y agoDid you know there are businesses out there that are still using programs made in DOS era (especially those made in FoxPro) and work perfectly? Or did you took a look at ATM's and seen that majority still have that WindowsXP look'n'feel? Not everybody needs the latest and greatest, you know? In that spirit, let's see your questions: 1-Once in a life time; 2-Yes;3-No;4-Nothing, see 1st answer.
- rektide 4y agoFd and ripgrep/rg are the two "new" alternatives I use on a regular basis, and which are just huge improvements to life. Both of these find/search programs respect your .gitignore files, which helps enormously & makes searching my department's entire codebase really fast. Fd is featured on Julia Evans' recent "New(ish) command line tools"[1] [1] https://jvns.ca/blog/2022/04/12/a-list-of-new-ish--command-line-tools/ https://jvns.ca/blog/2022/04/12/a-list-of-new-ish--command-l... https://news.ycombinator.com/item?id=31009313 https://news.ycombinator.com/item?id=31009313 (760 points, 37d ago, 244 comments)
- calvinmorrison 4y agoshout out to 'ack' as well
- girishso 4y agoIt's fd, ncdu and sd (sed alternative) for me. https://github.com/chmln/sd https://github.com/chmln/sd https://dev.yorhel.nl/ncdu https://dev.yorhel.nl/ncdu
- plandis 4y agoA while ago I came across this post: https://towardsdatascience.com/awesome-rust-powered-command-line-utilities-b5359c38692 https://towardsdatascience.com/awesome-rust-powered-command-... I’ve also been using bat and exa which are pretty good replacements for cat and ls, respectively. https://github.com/sharkdp/bat https://github.com/sharkdp/bat https://github.com/ogham/exa https://github.com/ogham/exa
- res0nat0r 4y agoscc is an insanely fast alternative to cloc: https://github.com/boyter/scc https://github.com/boyter/scc nnn is also my go to file tree navigation / file moving tool these days too: https://github.com/jarun/nnn https://github.com/jarun/nnn
- pdimitar 4y agoFor counting coding lines I use tokei and I like it: https://github.com/XAMPPRocky/tokei https://github.com/XAMPPRocky/tokei
- 0x00101010 4y agohttps://github.com/kamiyaa/joshuto https://github.com/kamiyaa/joshuto in favor of nnn.
- kbd 4y ago
- eterps 4y agoI love fd, but somehow I always get tripped up on this: fd # prints tree of current directory fd somedir/ # results in an error find # prints tree of current directory find somedir/ # prints tree of somedir/
- geodel 4y agoAh, same thing happens to me all the time. You are right, second one seems more intuitive and many tools old and new use this pattern.
- Johnny555 4y agoThat seems unfortunate, since my shell's autocomplete puts that trailing slash in there by default.
- eterps 4y agoThe trailing slash is not the issue here. With `fd` the first argument is the pattern to search for, not the starting point like in `find`. For example to find fonts.conf below /etc, with fd you would do: fd fonts.conf /etc And with find: find /etc -name fonts.conf In other words with find the first argument is always the starting point. And leaving it out implies the current directory as the starting point.
- joveian 4y agoThere are --search-path and --base-path options, so if you alias say fd='fd --search-path' you can then have the required first argument be the path to search. Personally, I find changing to the directory I want to search in less annoying than typing out the directory to search (I know the options exist from script use).
- mekster 4y agoIf it wasn't for find's muscle memory, fd has it right as you'd usually list what you want to do in the cli first and then list arbitrary number of targets in the end.
- colpabar 4y ago> The command name is 50% shorter* than find :-). I love this but if enough new tools keep doing this I might have to change some of my bash aliases :(
- wodenokoto 4y agoI find `find` so difficult to use that I usually do `find . | grep pattern` when I need to search for a file name.
- xtracto 4y agoOh, I thought I was kind of dumb for doing that :) happy to see that it's normal haha. I always find myself trying to remember: is it one dash? is it "name" or "iname" or whatnot.. pipe grep is way easier.
- dankle 4y agoSame. I have an ’alias fgr=”find|grep”. Stupid but gets the job done.
- b3morales 4y agoEven better, try fzf instead: do `find . | fzf`
- g4zj 4y agoWhat do you find difficult about using `find . -regex pattern`?
- 7373737373 4y agoIt amazes me how long it took for alternatives like fd to emerge The old ones must have caused years of wasted time
- lazyweb 4y ago
- NateEag 4y agoI want to love fd - I'm a big believer in the idea that CLIs don't have to be scary, intimidating things (see normals using Slack with /commands and keyboard shortcuts), and find has a gigantic hairball of a UI. 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't true. So it's hard for me to justify making the move. Same thing happens with things like the fish and oil shells - I have little doubt their UX is better than Bash's, but Bash is pretty ubiquitous. Emacs has this problem too, as an Emacs user. The UX is completely alien by current standards, but if you update the defaults you'll break a lot of people's existing configs. How do you get around backwards compatibility / universality UX roadblocks like this?
- eterps 4y agoIt just doesn't happen that often anymore that I need to ssh into a system. And my own systems have automatically synced dotfiles, making it mostly a non issue. (I'm using Syncthing for that) When writing scripts I usually fallback to traditional shells/commands for compatibilty. Unless I'm really sure I will be the only user.
- NateEag 4y agoI was more thinking of scripts, yeah, like you describe. Where I get hung up is, if I need to keep the traditional syntaxes in my head for scripting, why bother storing another one in my head for interactive use? ...that said, I do use ag and rg for other interactive tools, like cross-project search in Emacs.
- rmetzler 4y agoI know what you mean. I use fd and rg on my machine, but for scripts, Dockerfiles etc I tend to use find and grep, just because this is the „lingua franca“ of Unix/Linux.
- burntsushi 4y agoSame, and I'm the author of ripgrep! Unless the script is one that I wrote for myself in ~/bin, I use grep and find and standard tooling in shell scripts. The only exception is if there is a specific need for something ripgrep does. Usually it's for speed, but speed isn't always needed.
- reactjavascript 4y agoI just want my entire file system stored in Sqlite so I can query it myself
- samatman 4y agoOh hey look what I just found https://github.com/narumatt/sqlitefs https://github.com/narumatt/sqlitefs
- reactjavascript 4y ago>> "mount a sqlite database file as a normal filesystem" I'm looking to do the opposite. Given a location, recurse it, stat() each file and create the database.
- my69thaccount 4y agoYou could also make it as a Sqlite virtual table so it's dynamic. Also file data is available in osquery: https://osquery.io/schema/5.2.3/#file https://osquery.io/schema/5.2.3/#file
- samatman 4y agoIt's still not clear to me whether you want the files inside the database or just the metadata. The stat part suggests the latter? I guess I can see that, but now you have cache invalidation (someone else linked to Spotlight, which does this as a background process). SQLite files can be larger than any physical medium you can purchase so why not go the distance?
- neura 4y agoIf you happen to be using macOS, there's mdfind, which uses the spotlight database which is always kept up to date, unlike locate/updatedb, where updatedb is expensive to run, even if you've run it recently. I have yet to find a good solution for linux CLI... something that uses an internal database that is kept up to date with all directory structure changes. Maybe someone else has seen something cool for this? :D
- 4y ago
- mprovost 4y agoIt feels like we're in a third wave of innovation in Unix CLI tools. The first was from BSD in the late 70s/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's really taken off lately with tools being rewritten in Rust and challenging the old status quo.
- sbf501 4y agoThe only way for 3rd wave to work is if multiple distros agree to adopt it. Since these tools don't even agree on an interface, IMHO it wouldn't be much different than what we have. I also don't like the fact that some tools native skip things like what's in ".gitignore". I don't want a tool that does that by default. If there was a consortium to standardize a new *nix CLI, then maybe it could get some traction.
- calvinmorrison 4y agoWell, like zsh, and many other improvements on the shell, and gawk and other tooling that doesn't match other awk engines and so forth... you end up having two parallel realities. One for scripting, where you use the bare minimus that is acceptable to run on any server and it's guaranteed to be there, and then your user env where you have all your fun tools. The cool part is network transparency and forwarding environments and other things that plan9 plays with so that you can work locally, remotely.
- mprovost 4y agoThere was a consortium, and it did standardise Unix, and that's when everything stopped moving in the 90s. Standards are compromises and so all the commercial Unixes had to implement the lowest common denominator. Thankfully GNU didn't care, and the BSD tools were already better.
- sbf501 4y agoWhat was the consortium? I'd like to read up on it. LCD isn't always a bad thing, as it tends to weed out the niche one-offs.
- pdimitar 4y agoI use fd and rg a lot, integrated them with my scripts and even have some of them bound to keys. Insanely good and fast programs. Zero regrets. For a fuzzy finder I recently replaced fzf with peco. I like it better, it's very customizable.
- digisign 4y agoHmm, I already have a shell alias that does 90% of this. Doesn't parse .gitignore, but it's not a big problem for me. If it was I'd do `make clean` in the project. This is always installed and ready to go on any box I have my dotfiles. 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.
- marbex7 4y agofind 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.
- jonnycomputer 4y agoWhy would the tool want to ignore patterns in a .gitignore? It isn't a git tool...
- sfink 4y agoGenerated files. If you're searching for every place something shows up so you can change it, it's annoying to have to filter out the stuff that'll get updated automatically (and will mess up timestamps if you update manually.) Also, backup files. The fewer irrelevant results, the more useful a tool is.
- jonnycomputer 4y agoI'm not asking why someone would find it be useful.
- sfink 4y agoThe tool would want to use .gitignore files because it's useful. Also, it's far from the only non-VCS tool that uses VCS ignore files. rsync --cvs-exclude tar --exclude-vcs
- jonnycomputer 4y agoAgain, I'm not asking why someone would find it useful.
- sodality2 4y ago> Why would the tool want to ignore patterns in a .gitignore? > The tool would want to use .gitignore files because it's useful.
- jonnycomputer 4y agoSometimes a question isn't a question.
- spudlyo 4y agoI don't use `fd` on the command line because I have very ingrained `find` muscle memory, but it'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.
- bradwood 4y agoYup. Integrations with vim are really helpful here. But on the raw CLI it's tough to start unlearning the muscle memory
- yubiox 4y agoHow 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't have access to install anything on.
- petepete 4y agoIt's faster than find in that I don't need to read the manpage every time I use it.
- burntsushi 4y agoYou can speed up grep by using 'xargs' or 'parallel' because searching tends to be the bottleneck. But for 'find', the bottleneck tends to be directory traversal itself. It's hard to speed that up outside of the tool. fd's directory traversal is itself parallelized. The other reason why 'fd' might be faster than a similar 'find' command is that 'fd' respects your gitignore rules automatically and skips hidden files/directories. You could approximate that with 'find' by porting your gitignore rules to 'find' filters. You could also say that this is comparing apples-to-oranges, which is true, but only from the perspective of comparing equivalent workloads. From the perspective of the user experience, it's absolutely a valid comparison.
- lbrito 4y agoThere are some Unix tools I never get around to memorizing the syntax of, and always end up searching "how to"s. find is definitively one of them.
- whartung 4y agoThe singular habit I picked up way back in the day was to simply cope with what was available. There's all sorts of utilities and such. Emacs was a grand example at the time as well. Lots of better mousetraps. But when you bounce around to a lot of different machines, machines not necessarily in your control, "lowest common denominator" really starts to rear its ugly head. That vast majority of my command line concoctions are burned into muscle memory. 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.
- mongol 4y agoYes, to get by with what is available is a useful trait. No matter how good these tools are, I will often arrive at a prompt where they are unavailable.
- mekster 4y agoWhy don't you make them available in ~/bin and have a better shell life?
- jthrowsitaway 4y agoThis is fine and all, but there are also subtle differences in standard CLI tools depending on the implementation. I'm used to GNU stdutils, and butt heads with the macOS and BusyBox implementations.
- bradwood 4y agoThis. I have exa and rg and fd all installed but unlearning the find and grep muscle memory is hard. Occasionally I give the newer stuff a go and then end up stumbling over syntax differences and end up just going back to what I know.
- burntsushi 4y agoIf you ever give ripgrep a go, stumble over something and are inclined to: please post a Discussion question[1]. "beginner" or "stupid" questions are welcome. If you can show me what you know works with grep, for example, and are curious about an equivalent rg command, that could be a good question. I might be able to give you some "fundamental" answers to it that let you reason about the tools more from first principles, but on your terms. [1] - https://github.com/BurntSushi/ripgrep/discussions https://github.com/BurntSushi/ripgrep/discussions
- ibejoeb 4y agoI like the contemporary alternative to the classics. They make a lot of thing so much easier. I have a little mental block, though. It'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's a pretty common refrain, but it's real and practical when you've got embedded systems, bsds, linuxes, macs, etc. Even the difference between gnu and mac is clunky when I don't practice enough. For the same reason, with the notable exception of git, I use practically no aliases. If I could invent a product, maybe it would be one that enables effectively "forwarding" CLIs to a remote host shell.
- vehementi 4y agoYeah, same here. I am doing a good amount of ops/SRE stuff these days while supporting my services and find myself ssh'ing into: - very locked down bastions - hosts through a secure remote access VM thing that makes file transfer difficult - random docker containers in EKS (often through both of the above) Getting good at the basic tools is just unavoidable. I find myself manually typing `alias k = kubectl` a lot though :p
- robohoe 4y agoI'm with you. I find that I feel like I know Linux like the back of my hands because I can fluidly interface with stock tools with a breeze. These new tools are great but I just don't see them widely spread across many remote systems that I manage. Just managing those packages across a fleet sounds like a pain in the ass.
- dagw 4y agoThese new tools are great but I just don't see them widely spread across many remote systems I had smart, experience people tell me not to waste my time using the GNU tools for this exact reason back in the day
- mprovost 4y agoNothing like logging into a freshly installed Solaris system and having to configure it using Bourne shell, which didn't have job control or history. At least it had vi. Usually the first thing you would do is get enough networking going to download bash and the GNU tools. But there were always some old timers around who wanted to haze the youngsters by forcing you to do everything with "native" tools.
- ungawatkt 4y agoHey, fd. I don'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).
- 0x00101010 4y agoBecause no one mentioned it. procs. I love it as ps/top replacement.
- 0x00101010 4y agoAnd another one, because I've read ncdu so much. dua is very nice as well.
- Symmetry 4y agoOh, nice. Currently I just have myshell alias `fn` to `find -name $argv` but this looks cool.
- broses 4y agoUsually when I can't be bothered to remind myself the syntax for find, my go to these days is `echo **/*pattern*`. Of course, this is mainly just for small searches.
- tragomaskhalos 4y agoI use find all the time, but it is such a strange beast - it's as if there were a meeting among all the standard Unix utilities on look and feel and find missed the memo. But it's ubiquitous and I'm too old to change horses now anyway.
- pseudostem 4y agoI don't like find. Nor do I like vi (not vim, vi) and/or maybe others. I don't wish to stamp on someone's parade who's more accomplished than I am. But I think these "new" tools miss the point. I use vi because I know it exists on every(?) system ever. It'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. Would I go out of my way to install find on my system? Probably not.
- burntsushi 4y agoThey don't miss the point. We're well aware they aren't ubiquitous and that is indeed one of their costs.[1] If the old tools are working well for you, then keep using them! I used plain grep for well over a decade before writing ripgrep. Hell, sometimes I still use grep for precisely the reason you describe: it is ubiquitous. Also, not every grep behaves the same. Not even close. Unless you're being paranoid about how you use grep, it's likely you've used some feature that isn't in POSIX and thus isn't portable. Uniquity and portability aren't "the point." Uniquity is a benefit and portability can be a benefit or a cost, depending on how you look at it. [1] - https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#posix4ever https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#pos...
- pseudostem 4y agoI should have phrased this as a question, instead of being dismissively declarative. >If, upon hearing that "ripgrep can replace grep," you actually hear, "ripgrep can be used in every instance grep can be used, in exactly the same way, for the same use cases, with exactly the same bug-for-bug behavior," then no, ripgrep trivially cannot replace grep. Moreover, ripgrep will never replace grep. If, upon hearing that "ripgrep can replace grep," you actually hear, "ripgrep can replace grep in some cases and not in other use cases," then yes, that is indeed true! I think this statement says it all.
- burntsushi 4y agoYes, it's a persistent misunderstanding because communication is hard and folks aren't always exactly precise. It is very common to hear from someone, "ripgrep has replaced grep for me." You might even here people state it more objectively, like, "ripgrep is a grep replacement." The problem is that the word "replace" or "replacement" means different things to different people. So that FAQ item was meant to tease those meanings apart.
- lumb63 4y agoMaybe I’m just old fashioned but all these new command line utilities strike me as solutions in search of a problem. 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. I’d love to be told I’m wrong, because I feel like I’m missing something.
- MichaelDickens 4y ago'find' is slow to the point of being useless for me. It can never find the file I'm looking for before I give up waiting for it to finish running. So I'm excited if fd can provide the same functionality but run much faster.
- pphysch 4y agoAre you inadvertently hitting a big .git/ with every find?
- burntsushi 4y agoThe "new CLI utilities" aren't solving new problems. They are solving old problems with a different user experience, driven by changes in how folks do development (particularly the scales). Notice that I said "different" UX and not "better" UX. Reasonable people can disagree about whether the newer tools have better UX as an objective fact. Many folks very rightly find it very surprising that these tools will skip over things automatically by default. What is true, however, is that there are a lot of people who do see the UX of these tools as better for them. As the author of ripgrep, I hear the same thing over and over again: ripgrep replaced their ~/bin grep wrapper with a bunch of --exclude rules that filtered out files they didn't want to search. Because if you don't do that, a simple 'grep -r' can take a really fucking long time to run if you're working on a big project. And guess what: a lot of programmers these days work on big projects. (See previous comment about changes in scale.) So you don't really have a choice: you either write a wrapper around grep so that it doesn't take forever, or you use a "smarter" tool that utilizes existing information (gitignore) to effectively do that for you. That smarter tool typically comes with other improvements, because your simple "grep wrapper" probably doesn't use all of the cores on your machine. It could, but it probably doesn't. So when you switch over, it's like fucking magic: it does what you wanted and it does it better than your wrapper. Boom. Throw away that wrapper and you're good to go. That's what I did anyway. (I had several grep wrappers before I wrote ripgrep.) Every time these tools are discussed here, people say the same thing: "I don't see the point." It's a failure of imagination to look beyond your own use cases. If all you ever work on are smaller projects, then you're never going to care about the perf difference between ripgrep and grep. ripgrep has other improvements/changes, but nearly all of them are more niche than the UX changes and the perf improvements.
- ghostly_s 4y agoThis didn'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's `${file##*.}` syntax).
- amelius 4y agoI want a user friendly alternative to find's companion xargs.
- TedShiller 4y agofatal flaw: written in ruby
- HeadlessChild 4y agoIt is written in Rust and not Ruby.
- TedShiller 4y agoOh ok that’s much better
- racl101 4y agoFind is a powerful command but one for which it is hard to find good examples beyond the basics. So I'm glad for these new kinds of CLI tools.
- jwilk 4y agoDiscussed in 2017: https://news.ycombinator.com/item?id=15429390 https://news.ycombinator.com/item?id=15429390 (215 comments)
- unnouinceput 4y agoWindows test comparison on my machine - for finding all .jpg in my D: drive 1 - classic command prompt: "D:\>dir /s /b *.jpg > 2.txt" - time 5 seconds (4581 files) 2 - this little gizmo: "D:\>fd -e jpg > 1.txt" - time 1 second (same 4581 files) Conclusion: I have a new tool dropped in my System32 folder from now on. Thank you David Peter
- massysett 4y agoI would love a `find` with reverse polish notation, also known as postfix notation. Something like: find . --name this --name that --or or, for more complex: find . --name this --name that --or --modified 2022-05-20 --and I have some little personal CRUD apps and this sort of postfix notation works very well for them. I could write something like this but haven't gotten motivated to do it though.
- elromulous 4y agoI'm seriously curious, is this the first time this link is being submitted? Frequently, I try to submit a link, and it shows up as having been submitted. And I'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't apply to certain users?
- h_an_smei3 4y agoThat are a lot of dependencies for such a simple tool. I'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. [dependencies] ansi_term = "0.12" atty = "0.2" ignore = "0.4.3" num_cpus = "1.13" regex = "1.5.5" regex-syntax = "0.6" ctrlc = "3.2" humantime = "2.1" lscolors = "0.9" globset = "0.4" anyhow = "1.0" dirs-next = "2.0" normpath = "0.3.2" chrono = "0.4" once_cell = "1.10.0" [dependencies.clap] version = "3.1" features = ["suggestions", "color", "wrap_help", "cargo", "unstable-grouped"]
- h_an_smei3 4y agoHaven't there been unresolved security issues with chrono, a crate this one depends on? Chrono hasn't been updated for almost 2 years. Is the issue resolved or is there a security risk in using fd?
- HeadlessChild 4y agoWould it make sense to create a utils package with all these new rust based utilities? Something like "rustutils" with a resemblance to "coreutils".
- zikohh 4y agoSee this for a collection of alternatives for a modern unix commands. https://github.com/ibraheemdev/modern-unix https://github.com/ibraheemdev/modern-unix
- krnlpnc 4y agoDoes fd solve the annoying “the order of the command line arguments matters a ton” approach that find uses?
- HeadlessChild 4y agoWell this is saving me a ton of time as I'm basically migrating UID ownership of files for NFS shares that dates back to the 90's. According to my rough benchmarks between find and fd, fd is ~3 times faster.