Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ripgrep is faster than grep, ag, Git grep, ucg, pt, sift (2016)

blog.burntsushi.net

Post reply on HN
Print view View original

121–130 of 198 posts

Re: Ripgrep is faster than grep, ag, Git grep, ucg, pt, sift (2016)

#121

Post by ciroduran »

shoover wrote: post #87
fhlu wrote: post #74

Earlier quoted context omitted.

You can also add a small script to your WSL under `/usr/local/bin/git`: GIT_WINDOWS="/mnt/c/Program Files/Git/bin/git.exe" GIT_LINUX="/usr/bin/git" case "$(pwd -P)" in /mnt/?/*) case "$@" in # Needed to fix prompt, but it breaks things like paging, colours, etc rev-parse*) # running linux git for rev-parse seems faster, even without translating paths exec "$GIT_LINUX" "$@" ;; *) exec "$GIT_WINDOWS" -c color.ui=always…

Thank you. I will use this.

The code as written above only works if you haven't changed the mountpoint for your windows partition (i.e. from /mnt), consider that

Re: Ripgrep is faster than grep, ag, Git grep, ucg, pt, sift (2016)

#122

Post by Icathian »

Sander_Marechal wrote: post #109
tambourine_man wrote: post #43

Earlier quoted context omitted.

Vim is almost broken for me without fzf+rg. Feels like I’m manually grinding coffee instead of using electricity.

Which integration for ripgrep do you use with Vim?

Can't speak for OP, but I use telescope for neovim and I don't think I could use (neo)vim without it.

Re: Ripgrep is faster than grep, ag, Git grep, ucg, pt, sift (2016)

#123

Post by vasergen »

imakira wrote: post #62
stinos wrote: post #3

It's fast indeed. And I can't help keeping promoting the combination with fzf :) For those who want to try it out, this is a Powershell function but the same principle applies in any shell. Does ripgrep then puts fuzzy searching in the resulting files+text on top while showing context in bat: function frg { $result = rg --ignore-case --color=always --line-number --no-heading @Args | fzf --ansi ` --color 'hl:-1:underl…

I wrote a bash version of this: function frg { result=`rg --ignore-case --color=always --line-number --no-heading "$@" | fzf --ansi \ --color 'hl:-1:underline,hl+:-1:underline:reverse' \ --delimiter ':' \ --preview "bat --color=always {1} --theme='Solarized (light)' --highlight-line {2}" \ --preview-window 'up,60%,border-bottom,+{2}+3/3,~3'` file="${result%%:*}" linenumber=`echo "${result}" | cut -d: -f2` if [ ! -z "…

great stuff

Re: Ripgrep is faster than grep, ag, Git grep, ucg, pt, sift (2016)

#124

Post by bhaak »

burntsushi wrote: post #50
kmarc wrote: post #44

Earlier quoted context omitted.

Maybe I'm missing something but I only use it with AND conditions (usually in the form of 'foo 'bar and it only matches lines with foo AND bar both present)

A search for `rg -e foo -e bar` will return lines that match either foo or bar. Some lines may have both, but it isn't required. The standard way to run "AND" queries is through shell pipelines. That is, `rg foo | rg bar` will only print lines containing both. But composition usually comes with costs. The output reverts to the standard grep format and it doesn't interact nicely with contextual options like -C/--conte…

As I have overloaded my rg with a customized rg alias, I can't pipe multiple rg calls.

Otherwise it would look like this:

    # rg nokogiri | rg linux
    
    :11:Gemfile.lock:647:  nokogiri (1.15.5-x86_64-linux)
But that is a me problem.

The workaround is of course just to pipe into grep instead.

Re: Ripgrep is faster than grep, ag, Git grep, ucg, pt, sift (2016)

#125

Post by cb321 »

fsiefken wrote: post #52
wanderingmind wrote: post #12

Earlier quoted context omitted.

Infact I would recommend a step further to integrate rip-grep-all (rga) with fzf that can do a fuzzy search not just on text files but on all types of files including pdfs, zip files. More details here [1] [1] https://github.com/phiresky/ripgrep-all/wiki/fzf-Integration

That's really nice, thanks. Long ago there was the Google Desktop Search where you could 'Google' your local documents. But the difference is that that worked with an index, so I imagine it's faster if you have thousands of pdfs en epubs.

Even longer ago, there was `glimpse`: https://www.linuxjournal.com/article/1164 which is still available. [1] glimpse's index-builds are like 10X slower than `qgrep` mentioned elsethread. `qgrep` also seems to have faster search (though I only tried a few patterns) and `qgrep` does not allow spelling errors like `glimpse`.

Neither `glimpse` nor `qgrep`, to my knowledge, directly supports pre-processing / document conversion (like `pdftotext`), though I imagine this would be easy to add to either replicating Desktop Search. (Indirectly, at some space cost, you could always dump conversions into a shadow file hierarchy, index that, and then translate path names.)

[1] https://manpages.ubuntu.com/manpages/focal/man1/glimpse.1.ht...

Re: Ripgrep is faster than grep, ag, Git grep, ucg, pt, sift (2016)

#127

Post by taude »

stinos wrote: post #3

It's fast indeed. And I can't help keeping promoting the combination with fzf :) For those who want to try it out, this is a Powershell function but the same principle applies in any shell. Does ripgrep then puts fuzzy searching in the resulting files+text on top while showing context in bat: function frg { $result = rg --ignore-case --color=always --line-number --no-heading @Args | fzf --ansi ` --color 'hl:-1:underl…

This is pretty much my exact use of ripgrep, too. I use it as a starting point to zero in on files/projects in a several-hundred repo codebase, and then go from there....

Re: Ripgrep is faster than grep, ag, Git grep, ucg, pt, sift (2016)

#128

Post by taude »

benterix wrote: post #99
imakira wrote: post #62

Earlier quoted context omitted.

I wrote a bash version of this: function frg { result=`rg --ignore-case --color=always --line-number --no-heading "$@" | fzf --ansi \ --color 'hl:-1:underline,hl+:-1:underline:reverse' \ --delimiter ':' \ --preview "bat --color=always {1} --theme='Solarized (light)' --highlight-line {2}" \ --preview-window 'up,60%,border-bottom,+{2}+3/3,~3'` file="${result%%:*}" linenumber=`echo "${result}" | cut -d: -f2` if [ ! -z "…

I wrote a zsh version of this: function frg { result=$(rg --ignore-case --color=always --line-number --no-heading "$@" | fzf --ansi \ --color 'hl:-1:underline,hl+:-1:underline:reverse' \ --delimiter ':' \ --preview "bat --color=always {1} --theme='Solarized (light)' --highlight-line {2}" \ --preview-window 'up,60%,border-bottom,+{2}+3/3,~3') file=${result%%:*} linenumber=$(echo "${result}" | cut -d: -f2) if [[ -n "$f…

Awesome. Thanks. Saved me some time. I haven't used the fzf integration like this.

Re: Ripgrep is faster than grep, ag, Git grep, ucg, pt, sift (2016)

#129

Post by burntsushi »

bhaak wrote: post #124
burntsushi wrote: post #50

Earlier quoted context omitted.

A search for `rg -e foo -e bar` will return lines that match either foo or bar. Some lines may have both, but it isn't required. The standard way to run "AND" queries is through shell pipelines. That is, `rg foo | rg bar` will only print lines containing both. But composition usually comes with costs. The output reverts to the standard grep format and it doesn't interact nicely with contextual options like -C/--conte…

As I have overloaded my rg with a customized rg alias, I can't pipe multiple rg calls. Otherwise it would look like this: # rg nokogiri | rg linux :11:Gemfile.lock:647: nokogiri (1.15.5-x86_64-linux) But that is a me problem. The workaround is of course just to pipe into grep instead.

Or `\rg`, which will use the command directly and skip your alias.

Re: Ripgrep is faster than grep, ag, Git grep, ucg, pt, sift (2016)

#130

Post by eviks »

capableweb wrote: post #40
mariopt wrote: post #38

What are the reasons for grep not being replaced/improved? This topic seems a bit old by now.

There are multiple alternatives you can already use as an alternative, like ripgrep. What are you proposing, switching out the command `grep` for another utility? Sounds like that could introduce a ton of breakage, for little value. People who want a faster grep will use a different thing, while people who use grep can continue to use it. Sounds like an ideal situation already.

It still wastes time of all the people on the road to that realization, including the time spent looking for a better alternative
Post reply on HN