Hacker News Reader

Comment by wruza | Hacker News Reader

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?

View on HN

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 is not hugely important to me, but I wanted it to be at least comparably fast to find (that's why I decided to try out Rust for this project). Otherwise, nobody would even consider using it.

I know that it will not be for everyone and I also know that it's a lot to ask someone to learn a new tool, but I'm happy if there are some people that enjoy using it. I certainly do ;-)

any plans on implementing the exec command from find in fd?

I'm not entirely sure, yet, but I'd be happy to discuss this. A GitHub ticket would be the best place (https://github.com/sharkdp/fd/issues).

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

Much more error prone.

I have encountered edge cases with pipe and xargs. if there was something that made it simpler i'd be all for it. This project aims to make find usable and simpler so why not?

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

You can also add the --back option as an alias, so you don't need to type it in every time on systems where that is important. You could also use an environment variable to modify the behavior.

The GNU team did this when they added or changed behavior to the original tools. A lot of them have flags like -posix and such which give them a strict set of behaviors.

The most annoying part of find, for me, is stuff like exclusions, with `-prune -o ... -print`. Something like rsync's `--exclude` would be great.

Your point expresses the classic innovator's dilemma; in this case, impossible to improve usability if you have to maintain existing SLA forever.

I see the speed as a secondary concern relative to the simplified interface. This tool looks like it covers about 99% of my usage of find with a much simpler and terser syntax, and I'm looking forward to trying it.

It is interesting if

  alias fd=“function _fd(){find . -iregex ‘.*’$1’.*’};_fd”

would suffice for these 99? (not tested, but hope you got the idea)

The other big advantage is `more user-friendly`. Thus no backward compatibility. No doubt some people are used to the old patterns, but lots of people also prefer saner defaults.

I couldn’t use neither thing without man page for the first time. And remembering -name -iname -type* and -I -s comes only with practice.

* does fd find files by type, mtime, depth, logical operators? I missed that in readme. If not, maybe “just pattern” argument is not too fair at all.

I agree, but replacing find would be very hard, not only does people except it to work in a certain way, but tons of shell scripts also.

Exactly. Especially once you've come to a good understanding with a standard *nix tool/command.

It's probably the "I'm searching the entire disk for something" use case.

Reply on news.ycombinator.com