-f/--file flag faster?rg, why does it execute some other command?Yes. See the guide's section on configuration files.
Please consult ripgrep's CHANGELOG.
ripgrep is a project whose contributors are volunteers. A release schedule adds undue stress to said volunteers. Therefore, releases are made on a best effort basis and no dates will ever be given.
An exception to this can be high impact bugs. If a ripgrep release contains a significant regression, then there will generally be a strong push to get a patch release out with a fix. However, no promises are made.
Yes! Whenever ripgrep is compiled on a system with asciidoctor or asciidoc
present, then a man page is generated from ripgrep's argv parser. After
compiling ripgrep, you can find the man page like so from the root of the
repository:
$ find ./target -name rg.1 -print0 | xargs -0 ls -t | head -n1
./target/debug/build/ripgrep-79899d0edd4129ca/out/rg.1
Running man -l ./target/debug/build/ripgrep-79899d0edd4129ca/out/rg.1 will
show the man page in your normal pager.
Note that the man page's documentation for options is equivalent to the output
shown in rg --help. To see more condensed documentation (one line per flag),
run rg -h.
The man page is also included in all ripgrep binary releases.
Yes! Shell completions can be found in the
same directory as the man page
after building ripgrep. Zsh completions are maintained separately and committed
to the repository in complete/_rg.
Shell completions are also included in all ripgrep binary releases.
For bash, move rg.bash to
$XDG_CONFIG_HOME/bash_completion or /etc/bash_completion.d/.
For fish, move rg.fish to $HOME/.config/fish/completions/.
For zsh, move _rg to one of your $fpath directories.
For PowerShell, add . _rg.ps1 to your PowerShell
profile
(note the leading period). If the _rg.ps1 file is not on your PATH, do
. /path/to/_rg.ps1 instead.
By default, ripgrep uses parallelism to execute its search because this makes the search much faster on most modern systems. This in turn means that ripgrep has a non-deterministic aspect to it, since the interleaving of threads during the execution of the program is itself non-deterministic. This has the effect of printing results in a somewhat arbitrary order, and this order can change from run to run of ripgrep.
The only way to make the order of results consistent is to ask ripgrep to
sort the output. Currently, this will disable all parallelism. (On smaller
repositories, you might not notice much of a performance difference!) You
can achieve this with the --sort path flag.
There is more discussion on this topic here: https://github.com/BurntSushi/ripgrep/issues/152
See the guide's section on file encoding.
ripgrep's -z/--search-zip flag will cause it to search compressed files
automatically. Currently, this supports gzip, bzip2, xz, lzma, lz4, Brotli and
Zstd. Each of these requires requires the corresponding gzip, bzip2, xz,
lz4, brotli and zstd binaries to be installed on your system. (That is,
ripgrep does decompression by shelling out to another process.)
ripgrep currently does not search archive formats, so *.tar.gz files, for
example, are skipped.
The -U/--multiline flag enables ripgrep to report results that span over
multiple lines.
ripgrep's default regex engine does not support lookaround or backreferences. This is primarily because the default regex engine is implemented using finite state machines in order to guarantee a linear worst case time complexity on all inputs. Backreferences are not possible to implement in this paradigm, and lookaround appears difficult to do efficiently.
However, ripgrep optionally supports using PCRE2 as the regex engine instead of
the default one based on finite state machines. You can enable PCRE2 with the
-P/--pcre2 flag. For example, in the root of the ripgrep repo, you can easily
find all palindromes:
$ rg -P '(\w{10})\1'
tests/misc.rs
483: cmd.arg("--max-filesize").arg("44444444444444444444");
globset/src/glob.rs
1206: matches!(match7, "a*a*a*a*a*a*a*a*a", "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa");
If your version of ripgrep doesn't support PCRE2, then you'll get an error
message when you try to use the -P/--pcre2 flag:
$ rg -P '(\w{10})\1'
PCRE2 is not available in this build of ripgrep
Most of the releases distributed by the ripgrep project here on GitHub will come bundled with PCRE2 enabled. If you installed ripgrep through a different means (like your system's package manager), then please reach out to the maintainer of that package to see whether it's possible to enable the PCRE2 feature.
ripgrep has two flags related to colors:
--color controls when to use colors.--colors controls which colors to use.The --color flag accepts one of the following possible values: never,
auto, always or ansi. The auto value is the default and will cause
ripgrep to only enable colors when it is printing to a terminal. But if you
pipe ripgrep to a file or some other process, then it will suppress colors.
The --colors` flag is a bit more complicated. The general format is:
--colors '{type}:{attribute}:{value}'
{type} should be one of path, line, column or match. Each of these
correspond to the four different types of things that ripgrep will add color
to in its output. Select the type whose color you want to change.{attribute} should be one of fg, bg or style, corresponding to
foreground color, background color, or miscellaneous styling (such as whether
to bold the output or not).{value} is determined by the value of {attribute}. If
{attribute} is style, then {value} should be one of nobold,
bold, nointense, intense, nounderline or underline. If
{attribute} is fg or bg, then {value} should be a color.A color is specified by either one of eight of English names, a single 256-bit number or an RGB triple (with over 16 million possible values, or "true color").
The color names are red, blue, green, cyan, magenta, yellow,
white or black.
A single 256-bit number is a value in the range 0-255 (inclusive). It can
either be in decimal format (e.g., 62) or hexadecimal format (e.g., 0x3E).
An RGB triple corresponds to three numbers (decimal or hexadecimal) separated by commas.
As a special case, --colors '{type}:none' will clear all colors and styles
associated with {type}, which lets you start with a clean slate (instead of
building on top of ripgrep's default color settings).
Here's an example that makes highlights the matches with a nice blue background with bolded white text:
$ rg somepattern \
--colors 'match:none' \
--colors 'match:bg:0x33,0x66,0xFF' \
--colors 'match:fg:white' \
--colors 'match:style:bold'
Colors are an ideal candidate to set in your configuration file. See the question on emulating The Silver Searcher's output style for an example specific to colors.
First, see the previous question's answer on configuring colors.
Secondly, coloring on Windows is a bit complicated. If you're using a terminal
like Cygwin, then it's likely true color support already works out of the box.
However, if you are using a normal Windows console (cmd or PowerShell) and
a version of Windows prior to 10, then there is no known way to get true
color support. If you are on Windows 10 and using a Windows console, then
true colors should work out of the box with one caveat: you might need to
clear ripgrep's default color settings first. That is, instead of this:
$ rg somepattern --colors 'match:fg:0x33,0x66,0xFF'
you should do this
$ rg somepattern --colors 'match:none' --colors 'match:fg:0x33,0x66,0xFF'
This is because ripgrep might set the default style for match to bold, and
it seems like Windows 10's VT100 support doesn't permit bold and true color
ANSI escapes to be used simultaneously. The work-around above will clear
ripgrep's default styling, allowing you to craft it exactly as desired.
Type in color in cmd.exe (Command Prompt) and echo -ne "\033[0m" on
Unix-like systems to restore your original foreground color.
In PowerShell, you can add the following code to your profile which will
restore the original foreground color when Reset-ForegroundColor is called.
Including the Set-Alias line will allow you to call it with simply color.
powershell
$OrigFgColor = $Host.UI.RawUI.ForegroundColor
function Reset-ForegroundColor {
$Host.UI.RawUI.ForegroundColor = $OrigFgColor
}
Set-Alias -Name color -Value Reset-ForegroundColor
PR #187 fixed this, and it was later deprecated in
If you continue to have encoding problems, you can also force the encoding
that the console will use for printing to UTF-8 with
[System.Console]::OutputEncoding = [System.Text.Encoding]::UTF8. This
will also reset when PowerShell is restarted, so you can add that line
to your profile as well if you want to make the setting permanent.
Using ripgrep alone, you can't. ripgrep is a search tool that will never touch your files. However, the output of ripgrep can be piped to other tools that do modify files on disk. See this issue for more information.
sed is one such tool that can modify files on disk. sed can take a filename and a substitution command to search and replace in the specified file. Files containing matching patterns can be provided to sed using
rg foo --files-with-matches
The output of this command is a list of filenames that contain a match for
the foo pattern.
This list can be piped into xargs, which will split the filenames from
standard input into arguments for the command following xargs. You can use this
combination to pipe a list of filenames into sed for replacement. For example:
rg foo --files-with-matches | xargs sed -i 's/foo/bar/g'
will replace all instances of 'foo' with 'bar' in the files in which
ripgrep finds the foo pattern. The -i flag to sed indicates that you are
editing files in place, and s/foo/bar/g says that you are performing a
substitution of the pattren foo for bar, and that you are doing this
substitution globally (all occurrences of the pattern in each file).
Note: the above command assumes that you are using GNU sed. If you are using BSD sed (the default on macOS and FreeBSD) then you must modify the above command to be the following:
rg foo --files-with-matches | xargs sed -i '' 's/foo/bar/g'
The -i flag in BSD sed requires a file extension to be given to make backups
for all modified files. Specifying the empty string prevents file backups from
being made.
Finally, if any of your file paths contain whitespace in them, then you might need to delimit your file paths with a NUL terminator. This requires telling ripgrep to output NUL bytes between each path, and telling xargs to read paths delimited by NUL bytes:
rg foo --files-with-matches -0 | xargs -0 sed -i 's/foo/bar/g'
To learn more about sed, see the sed manual here.
Additionally, Facebook has a tool called fastmod that uses some of the same libraries as ripgrep and might provide a more ergonomic search-and-replace experience.
ripgrep is dual licensed under the Unlicense and MIT licenses. Specifically, you may use ripgrep under the terms of either license.
The reason why ripgrep is dual licensed this way is two-fold:
More specifically, ripgrep and all its dependencies are compatible with this licensing choice. In particular, ripgrep's dependencies (direct and transitive) will always be limited to permissive licenses. That is, ripgrep will never depend on code that is not permissively licensed. This means rejecting any dependency that uses a copyleft license such as the GPL, LGPL, MPL or any of the Creative Commons ShareAlike licenses. Whether the license is "weak" copyleft or not does not matter; ripgrep will not depend on it.
Yes and no.
If, upon hearing that "ripgrep can replace grep," you actually hear, "ripgrep can be used in every instance grep can be used, in exactly the same way, for the same use cases, with exactly the same bug-for-bug behavior," then no, ripgrep trivially cannot replace grep. Moreover, ripgrep will never replace grep.
If, upon hearing that "ripgrep can replace grep," you actually hear, "ripgrep can replace grep in some cases and not in other use cases," then yes, that is indeed true!
Let's go over some of those use cases in favor of ripgrep. Some of these may not apply to you. That's OK. There may be other use cases not listed here that do apply to you. That's OK too.
(For all claims related to performance in the following words, see my blog post introducing ripgrep.)
--exclude
rules or writing wrapper scripts, then grep might be sufficient. (I'm not
kidding, I myself did this with grep for almost a decade before writing
ripgrep.) But if you instead enjoy having a search tool respect your
.gitignore, then ripgrep might be perfect for you!grep -r search. However, if you're OK writing the occasional
find ./ -print0 | xargs -P8 -0 grep command, then maybe grep is good
enough.Here are some cases where you might not want to use ripgrep. The same caveats for the previous section apply.
When I first started writing ripgrep, I called it rep, intending it to be a
shorter variant of grep. Soon after, I renamed it to xrep since rep
wasn't obvious enough of a name for my taste. And also because adding x to
anything always makes it better, right?
Before ripgrep's first public release, I decided that I didn't like xrep. I
thought it was slightly awkward to type, and despite my previous praise of the
letter x, I kind of thought it was pretty lame. Being someone who really
likes Rust, I wanted to call it "rustgrep" or maybe "rgrep" for short. But I
thought that was just as lame, and maybe a little too in-your-face. But I
wanted to continue using r so I could at least pretend Rust had something to
do with it.
I spent a couple of days trying to think of very short words that began with
the letter r that were even somewhat related to the task of searching. I
don't remember how it popped into my head, but "rip" came up as something that
meant "fast," as in, "to rip through your text." The fact that RIP is also
an initialism for "Rest in Peace" (as in, "ripgrep kills grep") never really
dawned on me. Perhaps the coincidence is too striking to believe that, but
I didn't realize it until someone explicitly pointed it out to me after the
initial public release. I admit that I found it mildly amusing, but if I had
realized it myself before the public release, I probably would have pressed on
and chose a different name. Alas, renaming things after a release is hard, so I
decided to mush on.
Given the fact that ripgrep never was, is or will be a 100% drop-in replacement for grep, ripgrep is neither actually a "grep killer" nor was it ever intended to be. It certainly does eat into some of its use cases, but that's nothing that other tools like ack or The Silver Searcher weren't already doing.
As of now, you can't. While I believe the various efforts that are being undertaken to help fund FOSS are extremely important, they aren't a good fit for me. ripgrep is and I hope will remain a project of love that I develop in my free time. As such, involving money---even in the form of donations given without expectations---would severely change that dynamic for me personally.
Instead, I'd recommend donating to something else that is doing work that you find meaningful. If you would like suggestions, then my favorites are: