Live data from Hacker News

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

github.com

171–180 of 225 posts

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

#171
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 like tool called "just". It's simple command runner inspired by make.

https://github.com/casey/just

One could argue that tool like this makes no sense since make is installed almost everywhere but I'm already using fish shell so one more non standard tool makes no difference. I appreciate simplicity of "just".

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

#172
post #125

Earlier quoted context omitted.

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.

A couple of people have asked for it, but the ROI isn't worth it. Think about all the various POSIX compatibilities, locale support, subtle differences in flag meanings, supporting the different flavors of regex (BREs, EREs) and of course, all the various differences in the regex engine itself, such as leftmost-first vs leftmost-longest matching, and subcapture match locations as well. I feel like people significantl…

Is POSIXLY_CORRECT supposed to be a play on “politically correct”? If so that’s pretty amusing.

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

#174
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)…

Given that "moreutils" is taken, and Rust has a metallic theme, if this should happen the project should totally be called "oreutils".

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

#175
post #28
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.

> I'm curious why you (or anyone) uses -exec?

I already know how to use it. It works.

> It's often painfully slower than piping through xargs

I've tried it. It has different semantics. First attempt always leads to errors and doing the wrong things. I always have to come up with some workaround to make things work as I expect they would (i.e. how -exec does things by default).

This lack of confidence also means I would never dare using xargs for anything remotely destructive (like rm).

What reason do I have not to use -exec? Why swap a perfectly perfect hammer for a broken screwdriver?

Besides: IMO the timesaving aspects of find is not strictly tied to how fast find runs. It's tied to what I can automate.

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

#176

Earlier quoted context omitted.

A couple of people have asked for it, but the ROI isn't worth it. Think about all the various POSIX compatibilities, locale support, subtle differences in flag meanings, supporting the different flavors of regex (BREs, EREs) and of course, all the various differences in the regex engine itself, such as leftmost-first vs leftmost-longest matching, and subcapture match locations as well. I feel like people significantl…

Is POSIXLY_CORRECT supposed to be a play on “politically correct”? If so that’s pretty amusing.

RMS' original convention for requesting GNU tools be compatible with questionable legacy behaviour was POSIX_ME_HARDER, but he toned it down as a gesture of goodwill to the other members of the POSIX committee.

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

#177
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)…

httpie: https://github.com/jakubroztocil/httpie (cURL for humans)

Httpie is my goto http cli for all systems. Pretty much PostMan (that a lot of ppl use for no reason) but without annoying UI and on a single line. Formats JSON and colors it right in the terminal as well. Has a super nice query, header and post body syntax. Works well with sessions and cookies.

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

#178
post #136
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…

Nix[1] says hi.

[1]: https://nixos.org/nix/

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

#179
post #150

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…

>A high level, systems programming, relative new language is used to write software that outperforms the default tools. It does stretch “the alternative” meaning on it and only then outperforms, actually. But it is not a tool alternative, it is alternative to few use cases, which could be improved by contributing to original projects, but instead they do blind fragmentation. Efforts spent meaninglessly and destructiv…

> Efforts spent meaninglessly and destructively from the unix community pov.

I think the unix phylosophy Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". is better applied by this `fd` tool than `find`.

If some else replaces the set of features offered by `find` with other, faster, rust tools the effort would be quite welcomed.

> take rust hype, cv points, attention,

You're welcome to add to your CV all the ways you can use find.

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

#180

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

Yeah except in most places where `find` is used in day-to-day work it is just for `find -iname 'foo'`. Anything fancier is probably less than 10% of uses. Here is my .bash_history:

find .

find .

find

find .

find . -name "debug.csv"

find .

man find

find . -type f

find . -iname "signal"

Post reply on HN