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

91–100 of 225 posts

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

#91

Post by burntsushi »

j2kun wrote: post #90
burntsushi wrote: post #65

Earlier quoted context omitted.

> 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. I wrote some of the tools on coldtea's list, and I'm pretty much the same way in that I stick to distro tooling in vanilla setups. But I spend enough time on my local workstation that having "better" (read: creature comforts) is worth it there! But yeah, if you spend most of your time in…

Who makes the decision on what gets standardized into the distro?

The people in charge of the distro. Governance structures vary. And sometimes it's not just about who gets to decide, but also, the technical work required to do it. People need to put in the work to make Rust applications packageable according to the distro's standards. YMMV.

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

#92

Post by sjmulder »

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

entr, too: http://entrproject.org

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

#93

Post by lloeki »

sharkdp wrote: post #8
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.

Thank you for the feedback! '-exec' is not supported at the moment. It's definitely something I would consider adding. We do have '-0'/'--print0' to separate results by NULL, so 'fd' can be used in combination with 'xargs'.

Or parallel, which is slightly trickier to implement than xargs/-exec.

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

#94

Post by [deleted] »

burntsushi wrote: post #91
j2kun wrote: post #90

Earlier quoted context omitted.

Who makes the decision on what gets standardized into the distro?

The people in charge of the distro. Governance structures vary. And sometimes it's not just about who gets to decide, but also, the technical work required to do it. People need to put in the work to make Rust applications packageable according to the distro's standards. YMMV.

[deleted]

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

#95

Post by lkbm »

majewsky wrote: post #50

It's strange to advertise this as a find(1) replacement when it covers maybe 1% of find(1) use cases. find -type d -empty -delete find -type l -exec readlink -f {} + etc. are not covered at all.

100% of the time I consider using find, what I want is "dir/s foo". Step 1 is decide whether it's worth re-looking-up how to do it. I rarely remember--sometimes I think the man page will be helpful. It's not. ("man find" mentions "-name", which gives me an "illegal option" error. Maybe it's "--name"? Nope. Maybe it's "-n"? Nope. Maybe it's "-f"? Oooh, you have to do path and then add in options, unless those options are -H, -L, -P, -E, -X, -d, -s, or -x, in which case they go before the path? Of course, how silly of me.)

"fd filename" does exactly what I want, and what I'd expect. Gave me what I wanted on the first try.

For my purposes, find is fully replaced, with something actually usable. Small, simple utils are nifty.

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

#96

Post by giancarlostoro »

jhasse wrote: post #86
bm1362 wrote: post #82

Earlier quoted context omitted.

Just my experience, I'm sure there are other types of organizations. In most of my workplaces, having one developer's preferred tools installed as a build step might not pass review. I would be annoyed if fish was installed on all our prod boxes, for example. I'm glad these tools work for you and I hope the community keeps making them, I just threw in my perspective.

> I would be annoyed if fish was installed on all our prod boxes, for example. Why?

Wondering the same when you consider you don't have to login to fish as the default shell, it's all set per user. Even so, they can just turn it on once they log on.

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

#97

Post by bm1362 »

jhasse wrote: post #86
bm1362 wrote: post #82

Earlier quoted context omitted.

Just my experience, I'm sure there are other types of organizations. In most of my workplaces, having one developer's preferred tools installed as a build step might not pass review. I would be annoyed if fish was installed on all our prod boxes, for example. I'm glad these tools work for you and I hope the community keeps making them, I just threw in my perspective.

> I would be annoyed if fish was installed on all our prod boxes, for example. Why?

That was just a hyperbolic example, but I can think of a few superficial reasons:

1. Because you end up with a more complex Dockerfile. I've seen curls, clones etc during build - having a remote call for random tools in our build _feels_ like a bad practice.

2. There is also the issue that a fleet of application servers will have different tooling available, which can be frustrating in a pinch. I've done some gnarly things across many hosts, expecting a common set of tools. At AWS, we were responsible for non-nuclear team's services during oncall and would ssh to their boxes. Logging into a box with a different shell would be annoying.

[2] > for i in `cat hosts.txt`; do ssh $i '...'; done

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

#98

Post by lkbm »

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.

Oh, [star][star]! What I usually end up doing is:

1. ls [star]/foo

2. ls [star]/[star]/foo

3. ls [star]/[star]/[star]/foo

4. "I guess it doesn't exist."

[star][star] would have been useful to know. But now I have fd, so that's nice. :-)

Edit: Silly markdown.

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

#99

Post by dibujante »

sharkdp wrote: post #57
wruza wrote: post #41

Any plan to provide find compatibility for drop-in replacement? My find/locate usage patterns are not worth learning new sophisticated tool for 5sec speedup once a week, and I suspect that I’m not alone. This is the main problem of new tools — not repeating the old-familiar style makes it unattractive for non-aggressive users. Side question: why is speed important? Which tools use fd to gain required performance?

Thank you for the feedback. No, fd does not aim to be a drop-in replacement for find. It was actually designed as a "user-friendly" (I know, I know...) alternative to find for most of the use-cases: "fd pattern" vs. "find -iname ' pattern '", smart case, etc. Also, in my view, the colored output is not just a way to make it look fancy, but actually helps a lot when scanning a large output in the terminal. The speed i…

You could always add a --back(wards compatible) parameter that caused it to parse every other parameter like a `find` :)

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

#100

Post by giancarlostoro »

Karrot_Kream wrote: post #75

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

I rather always know up front what language something is coded in. For example if it were coded in Java or .NET people would want to know.
Post reply on HN