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

161–170 of 225 posts

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

#161

Post by laumars »

foo101 wrote: post #136
bm1362 wrote: post #63

Earlier quoted context omitted.

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…

What surprises me is that even after 25 years of the Internet, we cannot bring in new tools into our environment (be it a remote box I ssh into or a trimmed down docker image) on the fly. The popular package management tools rely heavily on FHS and like to install stuff into directories that require root permission. Imagine if there was a tool that could download binaries of modern tools from a certain repo and insta…

You can. There's nothing stopping you adding ~/bin to $PATH. Many compilers allow you to specify the destination location either via a ./configure flag (for example) or an environmental variable. Or there is always the option of doing a `make build` and then manually copying the binaries into your ~/bin directory without doing a `make install`

You can also add ~/lib (for example) to your LD_LIBRARY_PATH path if you wanted to install custom libraries and even have your own man page path too.

All of this is already possibly on Linux and Unix however I'm not sure it's something you actively want to encourage as allowing users to install whatever they want on servers lowers the security to the level of the worst user on that server. If it was really deemed necessary that users should be able to install whatever they want then I'd sooner roll out a dedicated VM per user so at least their damage is self-contained (barring any visible networked infrastructure)

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

#162

Post by RHSeeger »

jimktrains2 wrote: post #129
nine_k wrote: post #116

Earlier quoted context omitted.

Why it would be significantly better than using a pipe?

Because you'll have to pipe into xargs and then you have issues with spaces in file names, sometimes-exec is simpler for a single command.

You can use -print0 and -0 to handle spaces.

    find . -name \*.java -print0 |xargs -0 grep something

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

#163

Post by sharkdp »

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…

Thank you for the feedback.

> So, I would suggest that you don't call this an alternative to find; it's not. A replacement for shell globs, sure. A replacement for poor file finding in text editors, OK. Just... not find.

It's literally called "a simple [..] alternative to find" and the very first sentence in the README says that "it does not seek to mirror all of find's powerful functionality". I'm not sure anymore how far I have to back off until everyone will be okay with my "advertising" :-)

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

#164

Post by raverbashing »

majewsky wrote: post #66
raverbashing wrote: post #61

Earlier quoted context omitted.

1% of possible cases but 90% of actual usage I'd say

Then you have a different usage pattern than I do. For simple name globbing, I usually just use shell globs, e.g. ls src/**/*_test.go It might be marginally slower than find or FD, but it usually doesn't matter because I usually deal with a small number of files.

I just tried this and:

  ls (some dir)/**/*.py
  zsh: argument list too long
Yeah, I'll keep using find

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

#165

Post by rootlocus »

sidlls wrote: post #107
rootlocus wrote: post #74

Earlier quoted context omitted.

> The fact that Rust is used is uninteresting, considering there's nothing special about it as it pertains to the other advertised features. Considering the fact that a programming language's appeal is directly influenced by the size and accomplishments of its community, I'd say it's relevant. A high level, systems programming, relative new language is used to write software that outperforms the default tools. That's…

There is nothing interesting about the performance improvement that is a product of using a particular language, and particularly this language. It may as well have been written in Java or Haskell.

> There is nothing interesting about the performance improvement that is a product of using a particular language, and particularly this language.

I said it's "proof that the language has potential and encourages people to try it out". But you seem biased against it ("and particularly this language"), which makes for a poor argument.

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

#166

Post by coldtea »

laumars wrote: post #161
foo101 wrote: post #136

Earlier quoted context omitted.

What surprises me is that even after 25 years of the Internet, we cannot bring in new tools into our environment (be it a remote box I ssh into or a trimmed down docker image) on the fly. The popular package management tools rely heavily on FHS and like to install stuff into directories that require root permission. Imagine if there was a tool that could download binaries of modern tools from a certain repo and insta…

You can. There's nothing stopping you adding ~/bin to $PATH. Many compilers allow you to specify the destination location either via a ./configure flag (for example) or an environmental variable. Or there is always the option of doing a `make build` and then manually copying the binaries into your ~/bin directory without doing a `make install` You can also add ~/lib (for example) to your LD_LIBRARY_PATH path if you w…

>You can. There's nothing stopping you adding ~/bin to $PATH. Many compilers allow you to specify the destination location either via a ./configure flag (for example) or an environmental variable.

Of course you can, technically. The parent laments why it's not easier to achieve. Already you're talking about manually building for example. Where's a package manager that will allow for that too, not just the central repo? (not just asking if such manager exists in some form, asking where it is in modern popular distros).

>All of this is already possibly on Linux and Unix however I'm not sure it's something you actively want to encourage as allowing users to install whatever they want on servers lowers the security to the level of the worst user on that server.

Which also touches the parent's question. Why is it not easier AND safer? It's not like we don't have security models that allow for such things...

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

#167

Post by oblio »

dbaupp wrote: post #149
hehno wrote: post #141

I'm honestly wondering when will we have the whole coreutils rewritten in Rust.

https://github.com/uutils/coreutils is a long way along.

The docs don't say: is this meant to replace Busybox or the actual GNU coreutils? As in, all GNU features and flags (which are generally much more comprehensive and IMO nicer than plain old POSIX features).

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

#168

Post by masklinn »

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…

> 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-day work.

I completely agree with that.

And would in fact go slightly further: one of my huge annoyances with `find` is that I can never get alternative (-o) non-trivial patterns to work correctly, I think there's room for an alternative tool here but it should learn from set-theoretic API and make non-trivial predicates easy to write and test. Something like mercurial revsets — using fileset patterns and predicates instead of revs obviously — would be a godsend.

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

#169

Post by tangus »

sharkdp wrote: post #163
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…

Thank you for the feedback. > So, I would suggest that you don't call this an alternative to find; it's not. A replacement for shell globs, sure. A replacement for poor file finding in text editors, OK. Just... not find. It's literally called "a simple [..] alternative to find" and the very first sentence in the README says that "it does not seek to mirror all of find's powerful functionality". I'm not sure anymore h…

But in fact it does not seek to mirror _any_ of find's powerful functionality.

Maybe advertize it as "a better ls -R | grep -i"?

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

#170

Post by Sean1708 »

JepZ wrote: post #36
sharkdp wrote: post #9

Earlier quoted context omitted.

It will work for all git directories that are encountered. This behavior can be disabled with the '-I' flag, if needed. fd uses Rusts regex engine ( https://github.com/rust-lang/regex ) which is based on finite automata.

I am not sure if I find that a smart default as I frequently exclude generated files from git repositories and when want to find something I do not know why I would not like to find such a file if my pattern matches it. I would prefer to let the switch enable the .gitignore logic, but as I don't know the authors use-case, theirs might be valid too.

Surely the common case is that you don't want to search generated files? Or at least I personally am almost never interested in generated files because they're not the ones I'm going to be changing/doing stuff with.
Post reply on HN