5 ms·

What is ripgrep? Edit: Because I'm on a Zoom call that will never end. "ripgrep is a line-oriented search tool that recursively searches the current directory

What is ripgrep? Edit: Because I'm on a Zoom call that will never end. "ripgrep is a line-oriented search tool that recursively searches the current directory for a regex pattern. By default, ripgrep will respect gitignore rules and automatically skip hidden files/directories and binary files." https://github.com/BurntSushi/ripgrep https://github.com/BurntSushi/ripgrep

kibwen 4y ago
A grep alternative that optimizes for performance: https://github.com/BurntSushi/ripgrep https://github.com/BurntSushi/ripgrep . There are detailed performance comparisons and discussions in the readme there.
tmtvl 4y ago
A file searcher akin to grep, ack, or ag (aka the silver searcher) it's programmed in Rust so it is decently fast with good support for UTF-8. Unfortunately it defaults to parsing a git tree's gitignore file and skipping over files listed in it.
- stjohnswarts 4y ago
  just use --hidden, people shouldn't be afraid of typing an additional word. I prefer the defaults to keep things clean.
- kevincox 4y ago
  "decently fast" is a significant understatement. It is likely the fastest similar tool. (`git grep` may win due to not listing the directory tree and packed files and GNU grep is very fast if you don't use Unicode, but other than that ripgrep wins).
- Sohcahtoa82 4y ago
  > Unfortunately it defaults to parsing a git tree's gitignore file and skipping over files listed in it. That's a feature. Like, it's the entire point of ripgrep. It's designed to search through the things a developer actually cares about searching through. If you actually want to search everything, just use grep.
- enriquto 4y ago
  > it defaults to parsing a git tree's gitignore file and skipping over files listed in it Is that true? How could anybody think that this non-orthogonal monstrosity would make any sense?
  - nicoburns 4y ago
    It’s what you usually want when searching code bases. It includes all your source code but excludes generated code and build artefacts.
  - nrabulinski 4y ago
    Because you hardly ever want to grep through your build artifacts or node modules? I don’t remember any one time I had to explicitly tell ripgrep to search through all the files in a repository
    - tmtvl 4y ago
      Ah, someone who hasn't experienced the... experience of working on a project that does very esoteric autotools magic. I will agree that in a sane project setup you don't need to search through all files including build artifacts ignored by git.
      - iudqnolq 4y ago
        Even in an insane setup you generally don't want to search both at once. I find the pattern of first grepping non-ignored files and then cd-ing into my build directory or whatever and rerunning more helpful anyway.
  - cptroot 4y ago
    It's the correct default for me. I don't want to grep heinous output files by default, like my gigabytes of generated KML files. I appreciate that rg (and ag) ignores those files by default, and 90% of the people I show it to agree.
  - burntsushi 4y ago
    That monstrosity is easily one of the two most popular reasons cited by folks as being the reason why they use/like ripgrep. (With the other reason being performance.) Orthogality is a means to an end, not an end itself.
- burntsushi 4y ago
  It also defaults to ignoring hidden and binary files. It's also simultaneously the thing folks cite as their favorite part about ripgrep. The idea behind it is that it acts a heuristic for reducing false positives from your search results. For example, ripgrep replaced several little grep wrapper scripts I had in ~/bin. And fortunately the default behavior is easy to disable. `rg -uuu foo` will search the same stuff as `grep -r foo ./`, but will do it faster.
  - agateau 4y ago
    I love that ripgrep honors .gitignore, but the fact that it skips hidden files is annoying because of questionable decisions from tool makers who insist their configuration files should be hidden files. It is especially infuriating when working with GitHub and GitLab configuration directories. On the other hand I never want ripgrep to enter the .git directory. I recently came up with this alias to make ripgrep do what I want: do not skip hidden files, except for the .git directory: alias rg="rg --hidden --glob '!.git/'" (Note: if you try entering this alias interactively, you may have to escape the '!'...)
    - burntsushi 4y ago
      Yeah that alias is a good one, here are some other avenues: * The repo can add a `.ignore` or a `.rgignore` whitelisting things like `.github`. ripgrep will pick up that whitelist automatically and search `.github` even though it's hidden. But this relies on the repo adding ripgrep-specific config files, which is maybe not so realistic. (Or not universal enough to rely upon.) But it could work fine for repos under your control. * Add '!.github/' to, e.g., `~/.config/ripgrep/ignore`, and then add `alias rg="--ignore-file ~/.config/ripgrep/ignore"`. That will become a global ignore file (with low precedent) that will whitelist `.github` everywhere.
      - agateau 4y ago
        I use ripgrep everywhere, not only in my own repositories, so the first approach won't work for me. The second one, on the other hand, sounds like a really good idea, going to look into it, thanks. And of course, thanks for this wonderful tool!

kibwen 4y ago

A grep alternative that optimizes for performance: https://github.com/BurntSushi/ripgrep https://github.com/BurntSushi/ripgrep . There are detailed performance comparisons and discussions in the readme there.

tmtvl 4y ago

A file searcher akin to grep, ack, or ag (aka the silver searcher) it's programmed in Rust so it is decently fast with good support for UTF-8. Unfortunately it defaults to parsing a git tree's gitignore file and skipping over files listed in it.

stjohnswarts 4y ago
just use --hidden, people shouldn't be afraid of typing an additional word. I prefer the defaults to keep things clean.
kevincox 4y ago
"decently fast" is a significant understatement. It is likely the fastest similar tool. (`git grep` may win due to not listing the directory tree and packed files and GNU grep is very fast if you don't use Unicode, but other than that ripgrep wins).
Sohcahtoa82 4y ago
> Unfortunately it defaults to parsing a git tree's gitignore file and skipping over files listed in it. That's a feature. Like, it's the entire point of ripgrep. It's designed to search through the things a developer actually cares about searching through. If you actually want to search everything, just use grep.
enriquto 4y ago
> it defaults to parsing a git tree's gitignore file and skipping over files listed in it Is that true? How could anybody think that this non-orthogonal monstrosity would make any sense?
- nicoburns 4y ago
  It’s what you usually want when searching code bases. It includes all your source code but excludes generated code and build artefacts.
- nrabulinski 4y ago
  Because you hardly ever want to grep through your build artifacts or node modules? I don’t remember any one time I had to explicitly tell ripgrep to search through all the files in a repository
  - tmtvl 4y ago
    Ah, someone who hasn't experienced the... experience of working on a project that does very esoteric autotools magic. I will agree that in a sane project setup you don't need to search through all files including build artifacts ignored by git.
    - iudqnolq 4y ago
      Even in an insane setup you generally don't want to search both at once. I find the pattern of first grepping non-ignored files and then cd-ing into my build directory or whatever and rerunning more helpful anyway.
- cptroot 4y ago
  It's the correct default for me. I don't want to grep heinous output files by default, like my gigabytes of generated KML files. I appreciate that rg (and ag) ignores those files by default, and 90% of the people I show it to agree.
- burntsushi 4y ago
  That monstrosity is easily one of the two most popular reasons cited by folks as being the reason why they use/like ripgrep. (With the other reason being performance.) Orthogality is a means to an end, not an end itself.
burntsushi 4y ago
It also defaults to ignoring hidden and binary files. It's also simultaneously the thing folks cite as their favorite part about ripgrep. The idea behind it is that it acts a heuristic for reducing false positives from your search results. For example, ripgrep replaced several little grep wrapper scripts I had in ~/bin. And fortunately the default behavior is easy to disable. `rg -uuu foo` will search the same stuff as `grep -r foo ./`, but will do it faster.
- agateau 4y ago
  I love that ripgrep honors .gitignore, but the fact that it skips hidden files is annoying because of questionable decisions from tool makers who insist their configuration files should be hidden files. It is especially infuriating when working with GitHub and GitLab configuration directories. On the other hand I never want ripgrep to enter the .git directory. I recently came up with this alias to make ripgrep do what I want: do not skip hidden files, except for the .git directory: alias rg="rg --hidden --glob '!.git/'" (Note: if you try entering this alias interactively, you may have to escape the '!'...)
  - burntsushi 4y ago
    Yeah that alias is a good one, here are some other avenues: * The repo can add a `.ignore` or a `.rgignore` whitelisting things like `.github`. ripgrep will pick up that whitelist automatically and search `.github` even though it's hidden. But this relies on the repo adding ripgrep-specific config files, which is maybe not so realistic. (Or not universal enough to rely upon.) But it could work fine for repos under your control. * Add '!.github/' to, e.g., `~/.config/ripgrep/ignore`, and then add `alias rg="--ignore-file ~/.config/ripgrep/ignore"`. That will become a global ignore file (with low precedent) that will whitelist `.github` everywhere.
    - agateau 4y ago
      I use ripgrep everywhere, not only in my own repositories, so the first approach won't work for me. The second one, on the other hand, sounds like a really good idea, going to look into it, thanks. And of course, thanks for this wonderful tool!