Repository navigation
ugrep as find (fd) replacement #194
Description
Activity
Thanks for the feedback. I like your suggestion. Right now, ugrep can be used as a simple
find -path GLOB -printutility with theugrep -g/GLOB ""option using a pattern that matches anything, i.e."", andfind -name GLOB -printwithugrep -gGLOB "". With ugrep you can also control the recursion depth with--depth=nand short options-1,-2,-3etc. Whilefinddoes not search the file contents to match a regex pattern, it has lots more options to specify search constraints on files, as you know, using logical connectives. So it's a different beast, but some things that are handy withfindcould be considered forugrepI suppose. Do you have a specific use case or requirements thatfindalone does not meet andugrepalone does not meet?Reacted by Maor GordonSorry for the late reply. I have no incompatibles between fd and ugrep.
The main question was in efficiency. I read ugrep use some algorithms which are better than in grep or rg.
I'll try to simplify my initial question.
Can file searching be faster and more efficient with ugrep than with fd?Can file searching be faster and more efficient with ugrep than with fd?
I would think so, since
finddoesn't appear to search in parallel like ugrep does.ugrepandfindare different beasts through. Runningugrepwith a glob (see previous response) and then--filtercan run the specified--filtercommand on the files found.For example,
ugrep '' -g'*.txt' --filter='*:stat %'displays thestatoutput for alltxtfiles recursively found.Another example,
ugrep -3 -c '' -g'*.zip' --filter='*:unzip %'will expand all .zip files recursively up to 2 more subdirectory levels deep in the working directory (useunzip -t %to try out without expanding the files).The
--filteroption is abused to do this (with*to match any file extension so-gjust selects whatever you want). That's fine. For the second example I used-cto output the number of lines produced byunzip. Using-lto list may work, but there can be problems with the way this option terminates the pipe to the process early, without consuming allunzipoutput, thereby interrupting the unzip. Perhaps I should think of a way to avoid this and let -l (and -q) with--filteralways consume all process output.I'm sure some clever folks can come up with some examples for practical use cases to use
--filterthis way. If someone has ideas to push this further, then I very much like to hear more.@genivia-inc thanks for the reply.
It's quite interesting.You've mentioned find.
But how about comparison with fd?
https://github.com/sharkdp/fdBTW it would be cool to see similar benchmark for ugrep|find|fd as you've provided for ugrep|grep|rg|etc.
A use case that came to my mind immediately upon trying
ug -Q(interactive mode), is that it is similar to thefzf/fzyuser experience, and it would be nice to be able to search for file names interactively instead of (or narrow by file names in addition to) file contents. Maybe there's a way to do this withugrepand I just haven't figured it out?You can use
ALT-gto specify globs interactively in the TUI.Reacted by pvarga-dniReacted by pvarga-dniOption
-gGLOB(TUIALT-g) is improved in ugrep 7.4 to speed up searching one or multiple glob paths recursively. This update avoids excessive deep and wide recursion using the GLOB paths instead of just recursing and then checking the GLOBs.
Hello. Is it make sense in terms of efficient and performance to use ugrep as a replacement for find utils like gnu find or fd?