8 ms·
Find Files (Ff) – File Search Utility in Rust
- sagartewari01 8y agoWhat does this tool provide that I can't get from a wrapper around gnu find?
- ethelward 8y agoWhat does GNU find provides that I can't get from a wrapper around Perl?
- baq 8y agoprobably nothing, is that a problem?
- scbrg 8y agoNot a problem, but it's still a valid question. I'm all for people writing alternatives to existing tools. I've done so myself multiple times. But when you start promoting your alternative, "so what's does it do better?" is a very reasonable question for other people to ask. After all, they are the ones who need to invest time in learning the new tool, perhaps add it as a dependency in their tool chain/work flow - with all the downsides that has.
- atoav 8y agoThe readme states it is ~3 to 5 times faster. And it seems to have a more beginner friendly syntax. I am not aperson who just has to use the newest and gratest for the sake of it, but I’d take ripgrep/rg over grep whenever I have the choice.
- rkangel 8y agoIf nothing else - ability to easily compile for native Windows and work as expected (with no Cygwin/GnuWin32 fun).
- olejorgenb 8y ago- It frees you from writing the wrapper (duh) - It probably have more niceties than a 5min wrapper (color, friendly defaults, etc.) I've personally used a homemade find wrapper for years, but have now replaced it with `fd` (another find reimplementation). The advantages isn't huge, but I find the niceties I never bothered implementing - well - nice :) That being said: I did get burned by the default behavior of ignoring hidden files :D Would've been nice if it by default didn't show hidden matches, but printed on stderr - something like: $ fd thing foo/something ... >searching hidden files - ^C to abort< >hidden files found (29) - use `--hidden` to show<
- mbaeten 8y agoIt might also be valuable to projects like Redox.
- vishaltelangre 8y agoRelated discussion - https://www.reddit.com/r/rust/comments/av31ae/ff_find_files_by_name/ehcanyn/ https://www.reddit.com/r/rust/comments/av31ae/ff_find_files_....
- nurettin 8y agoWhy do "convert everything to rust" people appear to prefer solving already solved problems instead of focusing on problems we could not solve but are now possible thanks to Rust?
- pests 8y agoGuess we should all just stop doing anything then.
- empath75 8y agoIf you’re learning a language, reimplementing something that’s already been solved is a fairly standard learning exercise.
- carlmr 8y agoApart from the aspect that you're new to a language and just want to learn something you might make an improved version. ripgrep is a Rust version of grep. It's the fastest grep I know and it has better Unicode support than GNU grep (because of Rust language decisions). Looking at memory safety and portability it might also be a good idea to program them in Rust. There are whole classes of bugs that are excluded in Rust which still pop up every once in a while in some of our basic system tools.
- agumonkey 8y agoI guess porting something you know in a new language is one problem less.
- kome 8y agobecause people want to learn and practice...
- yoz-y 8y ago"If people did not reinvent the wheel we would be still rolling around on wooden logs" I for one am very happy with tools such as ripgrep and fd which are more or less just rewrites of decades old programs but are much faster and have generally better though out interfaces.
- saagarjha 8y agoHow does this compare to fd, which provides similar functionality and is also written in Rust?
- vishaltelangre 8y agoI have answered a similar question here - https://github.com/vishaltelangre/ff/issues/4 https://github.com/vishaltelangre/ff/issues/4.
- robert_foss 8y agoThere's also fd[1], which is written in rust and is super fast. [1] https://github.com/sharkdp/fd https://github.com/sharkdp/fd
- iruoy 8y agoI just did a little test. fd seems to be about 3 times as fast. Command | Mean [ms] | Min…Max [ms] -------------|---------------|--------------- `fd .conf /` | 525.6 ± 17.7 | 505.3…552.0 `ff .conf /` | 1760.8 ± 10.2 | 1744.6…1775.3
- Someone1234 8y agoLooking at the code, I believe because fd uses a loop, and ff uses function recursion to walk the path tree. Function recursion is easier to write, but definitely has some overhead.
- winstonewert 8y agoMy experience is that if you have to maintain your own stack (which you'd need to in order to recursively walk directories) its faster to use the builtin stack than to implement your own. Further, it seems that this would IO-bound not CPU-bound so whatever small overhead exists in recursion vs iteration will not be noticeable. I think the difference is rather that `fd` uses threads and `ff` does not.
- vishaltelangre 8y ago> `fd` uses threads and `ff` does not. Author here. This is true. ff does not use threads right now. I have started learning Rust just a few days ago. I am not quite yet familiar with advanced topics such as achieving parallelism using threads in Rust and other similar stuff. My knowledge of Rust is limited at this moment and I struggled to get the language concepts to work such as ownership, lifetimes, etc. I am sure that I will be able to improvise the ff's performance by some extent by gaining some more knowledge of Rust.
- imoverclocked 8y agoHere is a bash/zsh port: alias ff='find . | egrep'
- millstone 8y agoThe above is faster because it streams the results as it walks the directory tree.
- agumonkey 8y agoI hate myself for never thinking alias whenever I use a pattern 23 times an hour. Thanks
- olejorgenb 8y agoThis will show all files where any of the path matches, not just the leafs
- frutiger 8y ago`find . -type f -name "$1"` should give you that and potentially faster than GP since you don't need to do any I/O to a second process.
- mehrdadn 8y agoOr maybe use the built-in ff() { find . -regex ".*$1.*" "${@:2}"; };
- chewbacha 8y agoThat’s fun! I needed something like this and wrote my own a while ago. Choose to implement it with a different algorithm though instead of regex. https://github.com/kbacha/file-finder https://github.com/kbacha/file-finder
- wst_ 8y agoSomeone already opened an issue to make it ignore files specified in `.gitignore`. A `fd` is doing it, `rg` is doing it, now someone wants this to behave the same. I don't know. Maybe I have some really strange expectations but when I want to find a file and nothing comes up as a result, I want to be sure nothing is there. And I want to be sure without remembering bunch of command line options or setting up aliases everywhere I log in because, guess what, maybe they invented some other file with patterns to ignore. Is it only me?
- dangom 8y ago99.99% of the times you don't want to search for files that are in .gitignore. Ignoring by default is the sane default, as it reduces the amount of false positives. If you do want to search through all files, there's probably a flag that allows you to do that. You can alias your commands to `alias tool="tool --whatever-flag"`.
- burntsushi 8y agoThat's the great thing about these tools. There is no need to serve as fundamental tools of a system that conform to some ancient spec like POSIX. There is no need for that because those tools already exist and work well. So if that's the behavior you want, then just use those tools. They work exceptionally well when called by other programs, like shell scripts, because they have reasonably standardized behavior. But with these tools, we have the freedom to revisit old assumptions. One of those is smart filtering. I can't tell you how many people tell me that they enjoy that as a good default. Tools should make the fact that they do smart filtering very clear, because it can be surprising if you aren't expecting it. But otherwise, I'm not particularly sympathetic to your reasoning here because: 1) what I said above about standard tools being available and 2) these tools should have ways of disabling smart filtering. So if it bites you, it should bite you only once. After that, you either learn to like it, learn to setup an alias and forget about it, or ragequit the tool.
- lathiat 8y agoI got bitten recently by haproxy using the '!' prefix on .gitignore lines to negate previous lines. This resulted in ag silently not searching any of the code base at all. So if you're implementing .gitignore support, you may want to consider at worst bailing on files with this syntax (and perhaps other syntax that is not supported) ag bug: https://github.com/ggreer/the_silver_searcher/issues/1233 https://github.com/ggreer/the_silver_searcher/issues/1233
- madmax96 8y agoFirst, I have a problem with rewriting common utilities (like find, which also supports more search functionality than regex) while changing flags (e.g. `i` to ignore case to `s` - incidentally, grep also accepts `i` to ignore case). It makes it harder to explore the system interactively, particularly for beginners. Second, the utility already exists, and this version is significantly slower: > time ./ff '.*.cpp' ~/src/ > /dev/null real 0m1.195s user 0m0.488s sys 0m0.671s > time find -E ~/src/ -type f -regex '.*.cpp' > /dev/null real 0m0.880s user 0m0.407s sys 0m0.425s But wait! This is a totally unnatural use of find. If we use find like users actually do, we get even better performance: time find ~/src/ -name '*.cpp' > /dev/null real 0m0.553s user 0m0.181s sys 0m0.363s Hardly scientific. But it begs the question: who is this for?
- setr 8y agotbh find's command line interface is extremely unnatural, and that alone would justify a switch for me. Ofc, there's no reason that the program itself needs to be reimplemented beyond its argument parser, but that's not that concerning for me as long as its still fast enough
- deleted 8y ago[deleted]
- vishaltelangre 8y agoIn ff v0.1.3, the slowness is reduced to some extent. > ff '.*.js' ~/projects > /dev/null 5.79s user 14.77s system 97% cpu 21.024 total > find -E ~/projects -type f -regex '.*.js' > /dev/null 3.98s user 10.76s system 67% cpu 21.933 total
- vishaltelangre 8y agoIn ff v0.1.4, the results are dramatically improved. > ff '.*.js' ~/projects > /dev/null 7.59s user 24.21s system 337% cpu 9.413 total
- vram22 8y agoHere's a simple version of a file find command utility, written in D, minimal features, may be useful for beginners to D: Command line D utility - find files matching a pattern under a directory: https://jugad2.blogspot.com/2016/10/command-line-d-utility-find-files.html https://jugad2.blogspot.com/2016/10/command-line-d-utility-f... The D stdlib's dirEntries() function makes the job easy, for a basic one like this.
- vram22 8y agoAlso, related, a bunch of D command-line utilities, again may be good for beginners to learn a bit from: https://news.ycombinator.com/item?id=18338952 https://news.ycombinator.com/item?id=18338952