Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: A simple, fast and user-friendly alternative to find, written in Rust

github.com

Post reply on HN
Print view View original

151–160 of 225 posts

Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust

#151

Post by nitrogen »

yorwba wrote: post #125
burntsushi wrote: post #119

Earlier quoted context omitted.

There is a very simple response to this: if ripgrep were a 100% drop-in replacement for something like GNU grep, then there would be basically no point for it to exist in the first place. The whole point is that it is very similar but does some things differently that a lot of people consider "better." I imagine this is truish for the other tools mentioned in this thread as well. (And still other tools, like xsv, hav…

Have you considered making a "grep mode" for ripgrep? If it's triggered by the name of the binary, it could provide both the traditional flags as well as its own.

You could write yourself a wrapper that translates supported flags for you, then falls back to grep for anything weird.

Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust

#152

Post by asicsp »

derriz wrote: post #28
josteink wrote: post #4

My main usecase for find is not only finding files, but to do actions on them through -exec. Unless I’m missing something, that’s not supported with this tool.

I'm curious why you (or anyone) uses -exec? It's often painfully slower than piping through xargs and I find the syntax (the semicolon and braces and the required quoting/escaping) uncomfortable. I haven't used -exec in 20 years.

see a detailed discussion here: https://unix.stackexchange.com/questions/321697/why-is-loopi...

especially this quote:

> find's business is evaluating expressions -- not locating files. Yes, find certainly locates files; but that's really just a side effect.

Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust

#153

Post by [deleted] »

falcolas wrote: post #124

I'm sorry to be something of a negative Nancy - and I'm sure I'm a corner case - but this is not really an alternative to find. It's an alternative for your editor's fuzzy find and a better version of shell globs. The absense of -delete, -execdir, -mtime, and the ability to chain multiple patterns together for the non-trivial use-cases, means this is practically useless in most places where `find` is used in day-to-d…

[deleted]

Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust

#154

Post by tayo42 »

tyingq wrote: post #23
tayo42 wrote: post #14

Why is this faster then find?

"Concerning fd's speed, the main credit goes to the regex and ignore crates that are also used in ripgrep"

Should have been more clear heh. There was a benchmark that didn't use regex and seemed to turn off the ignore files feature. Im not familiar with rust or those crates Im assuming that's what those are there for?

Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust

#155

Post by OJFord »

Karrot_Kream wrote: post #75

Will we ever be able to promote a tool without talking about the programming language it is implemented in?

In a package manager I wouldn't expect to see it. On HN, especially as a Show HN, the audience has a much higher likelihood of being interested in digging into the code, perhaps even becoming a contributor. That makes the language used much more pertinent.

Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust

#156

Post by jpz »

z1mm32m4n wrote: post #42

I've found that fzf has replaced all uses of find for me except in scripts. fzf has the benefits of being bound to a single key binding and showing me results as I type, rather than after the command runs.

thanks v much for recommendation

Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust

#157

Post by noobermin »

falcolas wrote: post #124

I'm sorry to be something of a negative Nancy - and I'm sure I'm a corner case - but this is not really an alternative to find. It's an alternative for your editor's fuzzy find and a better version of shell globs. The absense of -delete, -execdir, -mtime, and the ability to chain multiple patterns together for the non-trivial use-cases, means this is practically useless in most places where `find` is used in day-to-d…

I'm with you in that I will probably not use this (the auto .gitignore reading freaks me out). Another elitist aside: I can usually tell that I won't want to use a tool when it has a mac os install option first under the downloads section on its page.

That said, the good thing about open source is you don't have to use it. I imagine the opinionated choices they made are popular amongst that crowd who seem like the types who mainly use the terminal to code--hence the .gitignore awareness; so, I imagine it's ok for others to use it if they find it makes themselves more productive for what they do. But, the good news is fd won't become a default anytime soon for that reason, so I have nothing to worry about this affecting me.

Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust

#158

Post by cstrahan »

bm1362 wrote: post #63
coldtea wrote: post #17

It would be nice to have a collection of modern/faster/saner alternatives to common unix tools and such utilities (made in rust or not) that becomes standard -- or at least easily installable in linux distros and OS X. Not for replacing those tools, but for supplementing them. Thinking of stuff like fd and: ripgrep: https://github.com/BurntSushi/ripgrep (grep/ag alt) xsv: https://github.com/BurntSushi/xsv (csv tool)…

I appreciate all these new incarnations of old school tools but end up sticking with the basics regardless. When I'm sshing into a box to figure out whats going on, my toolset is mostly limited to top, find, xargs, awk, grep, df, du etc. Even local development now, I'm mostly debugging on a docker container running alpine or ubuntu. Knowing the right incantations is useful in that context and keeps me from installing…

A potential solution that would allow you to have your cake (SSH into wherever) and eat it too (have your favorite tools on hand) would be: use a package manager on your hosts that allows for safe installation of per-user packages (that is, such package installation should have absolutely no effect on the system outside of the user’s environment. A logical implication here is that it should be possible to use multiple versions of each package, both inter- and intra-user) and per-user package installation should not require special privileges (i.e. you shouldn’t need to be root if, as per the previous requirement re: safety, per-user package installation has no effect on the rest of the system). Then you could log in and do your work with the best tools you know, rather than being constrained to what your distro (or your servers’ admins) deems useful enough to be installed by default.

It strikes me as an odd choice to accept the least common denominator of tools. As a technologist, that sounds frustrating. And as someone in leadership, I can’t imagine hamstringing my team by making them work within an environment that won’t let them use the best tools for the task at hand.

Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust

#159

Post by sharkdp »

wheresmyusern wrote: post #148

hey david, you can omit the 'static lifetime in the root directory string declarations if you want! https://github.com/rust-lang/rfcs/pull/1623

Thank you for the hint! Unfortunately, this is not in rust 1.16, which I currently still want to support.

Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust

#160

Post by sharkdp »

noobermin wrote: post #157
falcolas wrote: post #124

I'm sorry to be something of a negative Nancy - and I'm sure I'm a corner case - but this is not really an alternative to find. It's an alternative for your editor's fuzzy find and a better version of shell globs. The absense of -delete, -execdir, -mtime, and the ability to chain multiple patterns together for the non-trivial use-cases, means this is practically useless in most places where `find` is used in day-to-d…

I'm with you in that I will probably not use this (the auto .gitignore reading freaks me out). Another elitist aside: I can usually tell that I won't want to use a tool when it has a mac os install option first under the downloads section on its page. That said, the good thing about open source is you don't have to use it. I imagine the opinionated choices they made are popular amongst that crowd who seem like the ty…

> Another elitist aside: I can usually tell that I won't want to use a tool when it has a mac os install option first under the downloads section on its page.

This is only because it's so much harder to support every possible Linux distro. I actually don't use macOS on my own, but 'Homebrew' seems like a really nice package manager. (Also, the first install option is via "cargo" which is platform independent.)

Post reply on HN