rust/ripgrep
1
0
Fork 0
mirror of https://github.com/BurntSushi/ripgrep.git synced 2024-12-12 19:18:24 +02:00
Code Issues Releases Activity
4fec9ffca8
ripgrep/CHANGELOG.md

1579 lines
75 KiB
Markdown
Raw Normal View History

ignore: fix gitignore parsing bug for trailing \/ When a glob pattern ended with a \/, and since we permit backslash escapes, the glob parser gave a "dangling escape" error. Which is weird, because the \ is clearly not dangling. The issue is that the layer above the glob parser, the gitignore parser, was stripping the trailing / so that it wouldn't be part of the matching logic. Of course, stripping the trailing / while it is escaped without removing the backslash escape is wrong. So we do that here. Fixes #2236
2022-06-14 16:38:32 +02:00
TBD
===
changelog: add template for next entry
2021-06-12 14:43:49 +02:00
Unreleased changes. Release notes have not yet been written.
core: don't let context flags override eachother This matches the behavior of GNU grep which does not ignore before-context and after-context completely if the context flag is also provided. Note that this change wasn't done just to match GNU grep. In this case, GNU grep has the more sensible behavior. Fixes #2288, Closes #2451
2023-07-07 16:51:51 +02:00
**BREAKING CHANGES**
* `rg -C1 -A2` used to be equivalent to `rg -A2`, but now it is equivalent to
`rg -B1 -A2`. That is, `-A` and `-B` no longer completely override `-C`.
Instead, they only partially override `-C`.
doc: scrub mentions of asciidoc/asciidoctor This optional dependency is now finally dropped. So ends a long journey of trying to generate man pages in a lightweight and dependable way. The only thing I could figure out how to make work reliably was to just learn how to write roff myself. Yay.
2023-11-21 14:58:39 +02:00
Build process changes:
* ripgrep's shell completions and man page are now created by running ripgrep
with a new `--generate` flag. For example, `rg --generate man` will write a
man page in `roff` format on stdout. The release archives have not changed.
* The optional build dependency on `asciidoc` or `asciidoctor` has been
dropped. Previously, it was used to produce ripgrep's man page. ripgrep now
owns this process itself by writing `roff` directly.
ignore: use work-stealing stack instead of Arc<Mutex<Vec<_>>> This represents yet another iteration on how `ignore` enqueues and distributes work in parallel. The original implementation used a multi-producer/multi-consumer thread safe queue from crossbeam. At some point, I migrated to a simple `Arc<Mutex<Vec<_>>>` and treated it as a stack so that we did depth first traversal. This helped with memory usage in very wide directories. But it turns out that a naive stack-behind-a-mutex can be quite a bit slower than something that's a little smarter, such as a work-stealing stack used in this commit. My hypothesis for why this helps is that without the stealing component, work distribution can get stuck in sub-optimal configurations that depend on which directory entries get assigned to a particular worker. It's likely that this can result in some workers getting "more" work than others, just by chance, and thus remain idle. But the work-stealing approach heads that off. This does re-introduce a dependency on parts of crossbeam which is kind of a bummer, but it's carrying its weight for now. Closes #1823, Closes #2591 Ref https://github.com/sharkdp/fd/issues/28
2023-08-21 19:58:27 +02:00
Performance improvements:
changelog: add perf bug fix for \b Like the previous CHANGELOG entry, this marks a bug that was fixed likely with the introduction of regex 1.9: $ hyperfine "rg-13.0.0 -ic '\bfoo\b \bbar\b' git-3a06386e.txt" "rg -ic '\bfoo\b \bbar\b' git-3a06386e.txt" Benchmark 1: rg-13.0.0 -ic '\bfoo\b \bbar\b' git-3a06386e.txt Time (mean ± σ): 1.034 s ± 0.011 s [User: 1.030 s, System: 0.004 s] Range (min … max): 1.021 s … 1.053 s 10 runs Benchmark 2: rg -ic '\bfoo\b \bbar\b' git-3a06386e.txt Time (mean ± σ): 6.3 ms ± 0.3 ms [User: 4.6 ms, System: 1.6 ms] Range (min … max): 5.6 ms … 7.3 ms 343 runs Summary 'rg -ic '\bfoo\b \bbar\b' git-3a06386e.txt' ran 164.95 ± 7.70 times faster than 'rg-13.0.0 -ic '\bfoo\b \bbar\b' git-3a06386e.txt' This was not fixed by making \b itself faster, but rather, by improving inner literal extraction. In particular, if the regex doesn't have any literals extracted, then search time can still be quite slow: $ time rg-13.0.0 -ic '\b[a-z]{3}\b\s\b[a-z]{3}\b' git-3a06386e.txt 57538 real 0.427 user 0.423 sys 0.003 maxmem 46 MB faults 0 $ time rg -ic '\b[a-z]{3}\b\s\b[a-z]{3}\b' git-3a06386e.txt 57538 real 0.337 user 0.333 sys 0.003 maxmem 46 MB faults 0 But then again, so is grep, because grep doesn't benefit from any literal optimizations either: $ time grep -E -ic '\b[a-z]{3}\b\s\b[a-z]{3}\b' git-3a06386e.txt 62396 real 1.316 user 1.292 sys 0.007 maxmem 13 MB faults 7 The count mismatch should probably be investigated. Fixes #1760
2023-10-10 01:51:44 +02:00
* [PERF #1760](https://github.com/BurntSushi/ripgrep/issues/1760):
Make most searches with `\b` look-arounds (among others) much faster.
ignore: use work-stealing stack instead of Arc<Mutex<Vec<_>>> This represents yet another iteration on how `ignore` enqueues and distributes work in parallel. The original implementation used a multi-producer/multi-consumer thread safe queue from crossbeam. At some point, I migrated to a simple `Arc<Mutex<Vec<_>>>` and treated it as a stack so that we did depth first traversal. This helped with memory usage in very wide directories. But it turns out that a naive stack-behind-a-mutex can be quite a bit slower than something that's a little smarter, such as a work-stealing stack used in this commit. My hypothesis for why this helps is that without the stealing component, work distribution can get stuck in sub-optimal configurations that depend on which directory entries get assigned to a particular worker. It's likely that this can result in some workers getting "more" work than others, just by chance, and thus remain idle. But the work-stealing approach heads that off. This does re-introduce a dependency on parts of crossbeam which is kind of a bummer, but it's carrying its weight for now. Closes #1823, Closes #2591 Ref https://github.com/sharkdp/fd/issues/28
2023-08-21 19:58:27 +02:00
* [PERF #2591](https://github.com/BurntSushi/ripgrep/pull/2591):
Parallel directory traversal now uses work stealing for faster searches.
ignore: Avoid contention on num_pending Previously, every worker would increment the shared num_pending count on every new work item, and decrement it after finishing them, leading to lots of contention. Now, we only track the number of workers actively running, so there is no contention except when workers go to sleep or wake up. Closes #2642
2023-10-30 21:56:08 +02:00
* [PERF #2642](https://github.com/BurntSushi/ripgrep/pull/2642):
Parallel directory traversal has some contention reduced.
ignore: use work-stealing stack instead of Arc<Mutex<Vec<_>>> This represents yet another iteration on how `ignore` enqueues and distributes work in parallel. The original implementation used a multi-producer/multi-consumer thread safe queue from crossbeam. At some point, I migrated to a simple `Arc<Mutex<Vec<_>>>` and treated it as a stack so that we did depth first traversal. This helped with memory usage in very wide directories. But it turns out that a naive stack-behind-a-mutex can be quite a bit slower than something that's a little smarter, such as a work-stealing stack used in this commit. My hypothesis for why this helps is that without the stealing component, work distribution can get stuck in sub-optimal configurations that depend on which directory entries get assigned to a particular worker. It's likely that this can result in some workers getting "more" work than others, just by chance, and thus remain idle. But the work-stealing approach heads that off. This does re-introduce a dependency on parts of crossbeam which is kind of a bummer, but it's carrying its weight for now. Closes #1823, Closes #2591 Ref https://github.com/sharkdp/fd/issues/28
2023-08-21 19:58:27 +02:00
cli: make resolve_binary take COM executables into account When `resolve_binary()` attempts to resolve a path to a program on Windows while searching for a program in `PATH` without an extension, `ripgrep` will assume the extension of the file to be `.exe` as it's the *de facto* standard, which will work most (99.99%) of the time... ...unless the binary is a COM executable (we're on Windows, duh). Closes #2523
2023-05-30 02:08:06 +02:00
Feature enhancements:
ignore/types: tweak Gradle file types This PR extends Gradle file types with the following: - Kotlin DSL buildscripts (`*.gradle.kts`) - Gradle Java properties (`gradle.properties`) - wrapper files (`gradle-wrapper.*`) - wrapper scripts (`gradlew`, `gradlew.bat`) PR #2587
2023-08-21 00:49:02 +02:00
* Added or improved file type filtering for Ada, DITA, Elixir, Fuchsia, Gentoo,
ignore/types: add Prolog file types This improves the Prolog file type rules. * `.pl` is the most common extension in the wild, though `.pro` is preferred in places where file extension may clash with Perl[1]. * `.P` is used for compatibility with XSB Prolog dialect[2]. PR #2590 [1]: https://www.swi-prolog.org/pldoc/man?section=fileext [2]: https://www.swi-prolog.org/pldoc/man?section=xsb-source
2023-08-21 16:53:56 +02:00
Gradle, GraphQL, Markdown, Prolog, Raku, TypeScript, USD, V
cli: add --stop-on-nonmatch flag This causes ripgrep to stop searching an individual file after it has found a non-matching line. But this only occurs after it has found a matching line. Fixes #1790, Closes #1930
2021-07-07 18:50:23 +02:00
* [FEATURE #1790](https://github.com/BurntSushi/ripgrep/issues/1790):
Add new `--stop-on-nonmatch` flag.
cli: replace clap with lexopt and supporting code ripgrep began it's life with docopt for argument parsing. Then it moved to Clap and stayed there for a number of years. Clap has served ripgrep well, and it probably could continue to serve ripgrep well, but I ended up deciding to move off of it. Why? The first time I had the thought of moving off of Clap was during the 2->3->4 transition. I thought the 3.x and 4.x releases were great, but for me, it ended up moving a little too quickly. Since the release of 4.x was telegraphed around when 3.x came out, I decided to just hold off and wait to migrate to 4.x instead of doing a 3.x migration followed shortly by another 4.x migration. Of course, I just never ended up doing the migration at all. I never got around to it and there just wasn't a compelling reason for me to upgrade. While I never investigated it, I saw an upgrade as a non-trivial amount of work in part because I didn't encapsulate the usage of Clap enough. The above is just what got me started thinking about it. It wasn't enough to get me to move off of it on its own. What ended up pushing me over the edge was a combination of factors: * As mentioned above, I didn't want to run on the migration treadmill. This has proven to not be much of an issue, but at the time of the 2->3->4 releases, I didn't know how long Clap 4.x would be out before a 5.x would come out. * The release of lexopt[1] caught my eye. IMO, that crate demonstrates exactly how something new can arrive on the scene and just thoroughly solve a problem minimalistically. It has the docs, the reasoning, the simple API, the tests and good judgment. It gets all the weird corner cases right that Clap also gets right (and is part of why I was originally attracted to Clap). * I have an overall desire to reduce the size of my dependency tree. In part because a smaller dependency tree tends to correlate with better compile times, but also in part because it reduces my reliance and trust on others. It lets me be the "master" of ripgrep's destiny by reducing the amount of behavior that is the result of someone else's decision (whether good or bad). * I perceived that Clap solves a more general problem than what I actually need solved. Despite the vast number of flags that ripgrep has, its requirements are actually pretty simple. We just need simple switches and flags that support one value. No multi-value flags. No sub-commands. And probably a lot of other functionality that Clap has that makes it so flexible for so many different use cases. (I'm being hand wavy on the last point.) With all that said, perhaps most importantly, the future of ripgrep possibly demands a more flexible CLI argument parser. In today's world, I would really like, for example, flags like `--type` and `--type-not` to be able to accumulate their repeated values into a single sequence while respecting the order they appear on the CLI. For example, prior to this migration, `rg regex-automata -Tlock -ttoml` would not return results in `Cargo.lock` in this repository because the `-Tlock` always took priority even though `-ttoml` appeared after it. But with this migration, `-ttoml` now correctly overrides `-Tlock`. We would like to do similar things for `-g/--glob` and `--iglob` and potentially even now introduce a `-G/--glob-not` flag instead of requiring users to use `!` to negate a glob. (Which I had done originally to work-around this problem.) And some day, I'd like to add some kind of boolean matching to ripgrep perhaps similar to how `git grep` does it. (Although I haven't thought too carefully on a design yet.) In order to do that, I perceive it would be difficult to implement correctly in Clap. I believe that this last point is possible to implement correctly in Clap 2.x, although it is awkward to do so. I have not looked closely enough at the Clap 4.x API to know whether it's still possible there. In any case, these were enough reasons to move off of Clap and own more of the argument parsing process myself. This did require a few things: * I had to write my own logic for how arguments are combined into one single state object. Of course, I wanted this. This was part of the upside. But it's still code I didn't have to write for Clap. * I had to write my own shell completion generator. * I had to write my own `-h/--help` output generator. * I also had to write my own man page generator. Well, I had to do this with Clap 2.x too, although my understanding is that Clap 4.x supports this. With that said, without having tried it, my guess is that I probably wouldn't have liked the output it generated because I ultimately had to write most of the roff by hand myself to get the man page I wanted. (This also had the benefit of dropping the build dependency on asciidoc/asciidoctor.) While this is definitely a fair bit of extra work, it overall only cost me a couple days. IMO, that's a good trade off given that this code is unlikely to change again in any substantial way. And it should also allow for more flexible semantics going forward. Fixes #884, Fixes #1648, Fixes #1701, Fixes #1814, Fixes #1966 [1]: https://docs.rs/lexopt/0.3.0/lexopt/index.html
2023-10-17 00:05:39 +02:00
* [FEATURE #1814](https://github.com/BurntSushi/ripgrep/issues/1814):
Flags are now categorized in `-h/--help` output and ripgrep's man page.
complete: add extra-verbose support to _rg_types When the extra-verbose style is set for the types tag, completed types are displayed along with the patterns they correspond to. This can be enabled by e.g. adding the following to .zshrc: zstyle ':completion:*:rg:*:types' extra-verbose true This change also makes _rg_types use the actual rg specified on the command line to look up types, and it fixes a mangled complete-all style check Fixes #2195
2022-04-27 04:19:09 +02:00
* [FEATURE #2195](https://github.com/BurntSushi/ripgrep/issues/2195):
When `extra-verbose` mode is enabled in zsh, show extra file type info.
readme: add winget installation section Closes #2409
2023-02-04 04:14:14 +02:00
* [FEATURE #2409](https://github.com/BurntSushi/ripgrep/pull/2409):
Added installation instructions for `winget`.
changelog: mention shell completion generation feature Closes #2425
2023-11-22 21:46:03 +02:00
* [FEATURE #2425](https://github.com/BurntSushi/ripgrep/pull/2425):
Shell completions (and man page) can be created via `rg --generate`.
logging: show heuristic information and decision When one does not provide any paths to ripgrep to search, it has to guess between searching stdin and the current working directory. It is possible for this guess to be wrong, and having the heuristics and the choice in the debug logs is useful for diagnosing this. The failure mode here is still pretty bad because you need to know to reach for the `--debug` flag in the first place. Namely, the typical failure mode is that ripgrep tries to search stdin while the intent is for it to search the current working directory, and thus likely blocking forever waiting for data on stdin. (Arguably this is a problem with the process architecture that invokes ripgrep. It shouldn't give ripgrep an open stdin handle that isn't closed.) Closes #2524
2023-11-22 03:04:54 +02:00
* [FEATURE #2524](https://github.com/BurntSushi/ripgrep/issues/2524):
The `--debug` flag now indicates whether stdin or `./` is being searched.
cli: make -d a short flag for --max-depth Interestingly, ripgrep now only has two available ASCII letter short flags remaining: -k and -y. Closes #2643, Closes #2644
2023-11-22 01:07:18 +02:00
* [FEATURE #2643](https://github.com/BurntSushi/ripgrep/issues/2643):
Make `-d` a short flag for `--max-depth`.
cli: rejigger --version to include PCRE2 info This adds info about whether PCRE2 is available or not to the output of --version. Essentially, --version now subsumes --pcre2-version, although we do retain the former because it (usefully) emits an exit code based on whether PCRE2 is available or not. Closes #2645
2023-11-22 23:23:35 +02:00
* [FEATURE #2645](https://github.com/BurntSushi/ripgrep/issues/2645):
The `--version` output will now also contain PCRE2 availability information.
cli: make resolve_binary take COM executables into account When `resolve_binary()` attempts to resolve a path to a program on Windows while searching for a program in `PATH` without an extension, `ripgrep` will assume the extension of the file to be `.exe` as it's the *de facto* standard, which will work most (99.99%) of the time... ...unless the binary is a COM executable (we're on Windows, duh). Closes #2523
2023-05-30 02:08:06 +02:00
regex: update regression test Sadly, PCRE2 has different behavior (but doesn't panic). We should look into that, but for now, this is good enough. Also, update the CHANGELOG. Ref #1891
2021-06-12 22:22:30 +02:00
Bug fixes:
cli: replace clap with lexopt and supporting code ripgrep began it's life with docopt for argument parsing. Then it moved to Clap and stayed there for a number of years. Clap has served ripgrep well, and it probably could continue to serve ripgrep well, but I ended up deciding to move off of it. Why? The first time I had the thought of moving off of Clap was during the 2->3->4 transition. I thought the 3.x and 4.x releases were great, but for me, it ended up moving a little too quickly. Since the release of 4.x was telegraphed around when 3.x came out, I decided to just hold off and wait to migrate to 4.x instead of doing a 3.x migration followed shortly by another 4.x migration. Of course, I just never ended up doing the migration at all. I never got around to it and there just wasn't a compelling reason for me to upgrade. While I never investigated it, I saw an upgrade as a non-trivial amount of work in part because I didn't encapsulate the usage of Clap enough. The above is just what got me started thinking about it. It wasn't enough to get me to move off of it on its own. What ended up pushing me over the edge was a combination of factors: * As mentioned above, I didn't want to run on the migration treadmill. This has proven to not be much of an issue, but at the time of the 2->3->4 releases, I didn't know how long Clap 4.x would be out before a 5.x would come out. * The release of lexopt[1] caught my eye. IMO, that crate demonstrates exactly how something new can arrive on the scene and just thoroughly solve a problem minimalistically. It has the docs, the reasoning, the simple API, the tests and good judgment. It gets all the weird corner cases right that Clap also gets right (and is part of why I was originally attracted to Clap). * I have an overall desire to reduce the size of my dependency tree. In part because a smaller dependency tree tends to correlate with better compile times, but also in part because it reduces my reliance and trust on others. It lets me be the "master" of ripgrep's destiny by reducing the amount of behavior that is the result of someone else's decision (whether good or bad). * I perceived that Clap solves a more general problem than what I actually need solved. Despite the vast number of flags that ripgrep has, its requirements are actually pretty simple. We just need simple switches and flags that support one value. No multi-value flags. No sub-commands. And probably a lot of other functionality that Clap has that makes it so flexible for so many different use cases. (I'm being hand wavy on the last point.) With all that said, perhaps most importantly, the future of ripgrep possibly demands a more flexible CLI argument parser. In today's world, I would really like, for example, flags like `--type` and `--type-not` to be able to accumulate their repeated values into a single sequence while respecting the order they appear on the CLI. For example, prior to this migration, `rg regex-automata -Tlock -ttoml` would not return results in `Cargo.lock` in this repository because the `-Tlock` always took priority even though `-ttoml` appeared after it. But with this migration, `-ttoml` now correctly overrides `-Tlock`. We would like to do similar things for `-g/--glob` and `--iglob` and potentially even now introduce a `-G/--glob-not` flag instead of requiring users to use `!` to negate a glob. (Which I had done originally to work-around this problem.) And some day, I'd like to add some kind of boolean matching to ripgrep perhaps similar to how `git grep` does it. (Although I haven't thought too carefully on a design yet.) In order to do that, I perceive it would be difficult to implement correctly in Clap. I believe that this last point is possible to implement correctly in Clap 2.x, although it is awkward to do so. I have not looked closely enough at the Clap 4.x API to know whether it's still possible there. In any case, these were enough reasons to move off of Clap and own more of the argument parsing process myself. This did require a few things: * I had to write my own logic for how arguments are combined into one single state object. Of course, I wanted this. This was part of the upside. But it's still code I didn't have to write for Clap. * I had to write my own shell completion generator. * I had to write my own `-h/--help` output generator. * I also had to write my own man page generator. Well, I had to do this with Clap 2.x too, although my understanding is that Clap 4.x supports this. With that said, without having tried it, my guess is that I probably wouldn't have liked the output it generated because I ultimately had to write most of the roff by hand myself to get the man page I wanted. (This also had the benefit of dropping the build dependency on asciidoc/asciidoctor.) While this is definitely a fair bit of extra work, it overall only cost me a couple days. IMO, that's a good trade off given that this code is unlikely to change again in any substantial way. And it should also allow for more flexible semantics going forward. Fixes #884, Fixes #1648, Fixes #1701, Fixes #1814, Fixes #1966 [1]: https://docs.rs/lexopt/0.3.0/lexopt/index.html
2023-10-17 00:05:39 +02:00
* [BUG #884](https://github.com/BurntSushi/ripgrep/issues/884):
Don't error when `-v/--invert-match` is used multiple times.
changelog: add bug fix for \b This was probably fixed in a past commit where I bumped the regex engine to 1.9 (or perhaps more precisely, regex-automata 0.3). But I didn't track it as fixed at the time. Fixes #1275
2023-10-10 01:44:59 +02:00
* [BUG #1275](https://github.com/BurntSushi/ripgrep/issues/1275):
Fix bug with `\b` assertion in the regex engine.
cli: replace clap with lexopt and supporting code ripgrep began it's life with docopt for argument parsing. Then it moved to Clap and stayed there for a number of years. Clap has served ripgrep well, and it probably could continue to serve ripgrep well, but I ended up deciding to move off of it. Why? The first time I had the thought of moving off of Clap was during the 2->3->4 transition. I thought the 3.x and 4.x releases were great, but for me, it ended up moving a little too quickly. Since the release of 4.x was telegraphed around when 3.x came out, I decided to just hold off and wait to migrate to 4.x instead of doing a 3.x migration followed shortly by another 4.x migration. Of course, I just never ended up doing the migration at all. I never got around to it and there just wasn't a compelling reason for me to upgrade. While I never investigated it, I saw an upgrade as a non-trivial amount of work in part because I didn't encapsulate the usage of Clap enough. The above is just what got me started thinking about it. It wasn't enough to get me to move off of it on its own. What ended up pushing me over the edge was a combination of factors: * As mentioned above, I didn't want to run on the migration treadmill. This has proven to not be much of an issue, but at the time of the 2->3->4 releases, I didn't know how long Clap 4.x would be out before a 5.x would come out. * The release of lexopt[1] caught my eye. IMO, that crate demonstrates exactly how something new can arrive on the scene and just thoroughly solve a problem minimalistically. It has the docs, the reasoning, the simple API, the tests and good judgment. It gets all the weird corner cases right that Clap also gets right (and is part of why I was originally attracted to Clap). * I have an overall desire to reduce the size of my dependency tree. In part because a smaller dependency tree tends to correlate with better compile times, but also in part because it reduces my reliance and trust on others. It lets me be the "master" of ripgrep's destiny by reducing the amount of behavior that is the result of someone else's decision (whether good or bad). * I perceived that Clap solves a more general problem than what I actually need solved. Despite the vast number of flags that ripgrep has, its requirements are actually pretty simple. We just need simple switches and flags that support one value. No multi-value flags. No sub-commands. And probably a lot of other functionality that Clap has that makes it so flexible for so many different use cases. (I'm being hand wavy on the last point.) With all that said, perhaps most importantly, the future of ripgrep possibly demands a more flexible CLI argument parser. In today's world, I would really like, for example, flags like `--type` and `--type-not` to be able to accumulate their repeated values into a single sequence while respecting the order they appear on the CLI. For example, prior to this migration, `rg regex-automata -Tlock -ttoml` would not return results in `Cargo.lock` in this repository because the `-Tlock` always took priority even though `-ttoml` appeared after it. But with this migration, `-ttoml` now correctly overrides `-Tlock`. We would like to do similar things for `-g/--glob` and `--iglob` and potentially even now introduce a `-G/--glob-not` flag instead of requiring users to use `!` to negate a glob. (Which I had done originally to work-around this problem.) And some day, I'd like to add some kind of boolean matching to ripgrep perhaps similar to how `git grep` does it. (Although I haven't thought too carefully on a design yet.) In order to do that, I perceive it would be difficult to implement correctly in Clap. I believe that this last point is possible to implement correctly in Clap 2.x, although it is awkward to do so. I have not looked closely enough at the Clap 4.x API to know whether it's still possible there. In any case, these were enough reasons to move off of Clap and own more of the argument parsing process myself. This did require a few things: * I had to write my own logic for how arguments are combined into one single state object. Of course, I wanted this. This was part of the upside. But it's still code I didn't have to write for Clap. * I had to write my own shell completion generator. * I had to write my own `-h/--help` output generator. * I also had to write my own man page generator. Well, I had to do this with Clap 2.x too, although my understanding is that Clap 4.x supports this. With that said, without having tried it, my guess is that I probably wouldn't have liked the output it generated because I ultimately had to write most of the roff by hand myself to get the man page I wanted. (This also had the benefit of dropping the build dependency on asciidoc/asciidoctor.) While this is definitely a fair bit of extra work, it overall only cost me a couple days. IMO, that's a good trade off given that this code is unlikely to change again in any substantial way. And it should also allow for more flexible semantics going forward. Fixes #884, Fixes #1648, Fixes #1701, Fixes #1814, Fixes #1966 [1]: https://docs.rs/lexopt/0.3.0/lexopt/index.html
2023-10-17 00:05:39 +02:00
* [BUG #1648](https://github.com/BurntSushi/ripgrep/issues/1648):
Fix bug where sometimes short flags with values, e.g., `-M 900`, would fail.
* [BUG #1701](https://github.com/BurntSushi/ripgrep/issues/1701):
Fix bug where some flags could not be repeated.
ignore: fix filtering when searching subdirectories When searching subdirectories the path was not correctly built and included duplicate parts. This fix will remove the duplicate part if possible. Fixes #1757, Closes #2295
2022-08-29 22:32:29 +02:00
* [BUG #1757](https://github.com/BurntSushi/ripgrep/issues/1757):
Fix bug when searching a sub-directory didn't have ignores applied correctly.
regex: update regression test Sadly, PCRE2 has different behavior (but doesn't panic). We should look into that, but for now, this is good enough. Also, update the CHANGELOG. Ref #1891
2021-06-12 22:22:30 +02:00
* [BUG #1891](https://github.com/BurntSushi/ripgrep/issues/1891):
Fix bug when using `-w` with a regex that can match the empty string.
changelog: add #1911 bug fix
2021-06-26 18:57:11 +02:00
* [BUG #1911](https://github.com/BurntSushi/ripgrep/issues/1911):
Disable mmap searching in all non-64-bit environments.
cli: replace clap with lexopt and supporting code ripgrep began it's life with docopt for argument parsing. Then it moved to Clap and stayed there for a number of years. Clap has served ripgrep well, and it probably could continue to serve ripgrep well, but I ended up deciding to move off of it. Why? The first time I had the thought of moving off of Clap was during the 2->3->4 transition. I thought the 3.x and 4.x releases were great, but for me, it ended up moving a little too quickly. Since the release of 4.x was telegraphed around when 3.x came out, I decided to just hold off and wait to migrate to 4.x instead of doing a 3.x migration followed shortly by another 4.x migration. Of course, I just never ended up doing the migration at all. I never got around to it and there just wasn't a compelling reason for me to upgrade. While I never investigated it, I saw an upgrade as a non-trivial amount of work in part because I didn't encapsulate the usage of Clap enough. The above is just what got me started thinking about it. It wasn't enough to get me to move off of it on its own. What ended up pushing me over the edge was a combination of factors: * As mentioned above, I didn't want to run on the migration treadmill. This has proven to not be much of an issue, but at the time of the 2->3->4 releases, I didn't know how long Clap 4.x would be out before a 5.x would come out. * The release of lexopt[1] caught my eye. IMO, that crate demonstrates exactly how something new can arrive on the scene and just thoroughly solve a problem minimalistically. It has the docs, the reasoning, the simple API, the tests and good judgment. It gets all the weird corner cases right that Clap also gets right (and is part of why I was originally attracted to Clap). * I have an overall desire to reduce the size of my dependency tree. In part because a smaller dependency tree tends to correlate with better compile times, but also in part because it reduces my reliance and trust on others. It lets me be the "master" of ripgrep's destiny by reducing the amount of behavior that is the result of someone else's decision (whether good or bad). * I perceived that Clap solves a more general problem than what I actually need solved. Despite the vast number of flags that ripgrep has, its requirements are actually pretty simple. We just need simple switches and flags that support one value. No multi-value flags. No sub-commands. And probably a lot of other functionality that Clap has that makes it so flexible for so many different use cases. (I'm being hand wavy on the last point.) With all that said, perhaps most importantly, the future of ripgrep possibly demands a more flexible CLI argument parser. In today's world, I would really like, for example, flags like `--type` and `--type-not` to be able to accumulate their repeated values into a single sequence while respecting the order they appear on the CLI. For example, prior to this migration, `rg regex-automata -Tlock -ttoml` would not return results in `Cargo.lock` in this repository because the `-Tlock` always took priority even though `-ttoml` appeared after it. But with this migration, `-ttoml` now correctly overrides `-Tlock`. We would like to do similar things for `-g/--glob` and `--iglob` and potentially even now introduce a `-G/--glob-not` flag instead of requiring users to use `!` to negate a glob. (Which I had done originally to work-around this problem.) And some day, I'd like to add some kind of boolean matching to ripgrep perhaps similar to how `git grep` does it. (Although I haven't thought too carefully on a design yet.) In order to do that, I perceive it would be difficult to implement correctly in Clap. I believe that this last point is possible to implement correctly in Clap 2.x, although it is awkward to do so. I have not looked closely enough at the Clap 4.x API to know whether it's still possible there. In any case, these were enough reasons to move off of Clap and own more of the argument parsing process myself. This did require a few things: * I had to write my own logic for how arguments are combined into one single state object. Of course, I wanted this. This was part of the upside. But it's still code I didn't have to write for Clap. * I had to write my own shell completion generator. * I had to write my own `-h/--help` output generator. * I also had to write my own man page generator. Well, I had to do this with Clap 2.x too, although my understanding is that Clap 4.x supports this. With that said, without having tried it, my guess is that I probably wouldn't have liked the output it generated because I ultimately had to write most of the roff by hand myself to get the man page I wanted. (This also had the benefit of dropping the build dependency on asciidoc/asciidoctor.) While this is definitely a fair bit of extra work, it overall only cost me a couple days. IMO, that's a good trade off given that this code is unlikely to change again in any substantial way. And it should also allow for more flexible semantics going forward. Fixes #884, Fixes #1648, Fixes #1701, Fixes #1814, Fixes #1966 [1]: https://docs.rs/lexopt/0.3.0/lexopt/index.html
2023-10-17 00:05:39 +02:00
* [BUG #1966](https://github.com/BurntSushi/ripgrep/issues/1966):
Fix bug where ripgrep can panic when printing to stderr.
doc: improve -r/--replace flag syntax docs Fixes #2108, Closes #2123
2022-01-12 12:18:20 +02:00
* [BUG #2108](https://github.com/BurntSushi/ripgrep/issues/2108):
Improve docs for `-r/--replace` syntax.
cli: '--no-ignore-dot' should also '.rgignore' Fixes #2198, Closes #2202
2022-05-08 15:48:56 +02:00
* [BUG #2198](https://github.com/BurntSushi/ripgrep/issues/2198):
Fix bug where `--no-ignore-dot` would not ignore `.rgignore`.
core: don't let context flags override eachother This matches the behavior of GNU grep which does not ignore before-context and after-context completely if the context flag is also provided. Note that this change wasn't done just to match GNU grep. In this case, GNU grep has the more sensible behavior. Fixes #2288, Closes #2451
2023-07-07 16:51:51 +02:00
* [BUG #2288](https://github.com/BurntSushi/ripgrep/issues/2288):
`-A` and `-B` now only each partially override `-C`.
ignore: fix gitignore parsing bug for trailing \/ When a glob pattern ended with a \/, and since we permit backslash escapes, the glob parser gave a "dangling escape" error. Which is weird, because the \ is clearly not dangling. The issue is that the layer above the glob parser, the gitignore parser, was stripping the trailing / so that it wouldn't be part of the matching logic. Of course, stripping the trailing / while it is escaped without removing the backslash escape is wrong. So we do that here. Fixes #2236
2022-06-14 16:38:32 +02:00
* [BUG #2236](https://github.com/BurntSushi/ripgrep/issues/2236):
Fix gitignore parsing bug where a trailing `\/` resulted in an error.
cli: fix non-path sorting behavior Previously, sorting worked by sorting the parents and then sorting the children within each parent. This was done during traversal, but it only works when sorting parents preserves the overall order. This generally only works for '--sort path' in ascending order. This commit fixes the rest of the sorting behavior by collecting all of the paths to search and then sorting them before searching. We only collect all of the paths when sorting was requested. Fixes #2243, Closes #2361
2022-11-28 06:36:15 +02:00
* [BUG #2243](https://github.com/BurntSushi/ripgrep/issues/2243):
Fix `--sort` flag for values other than `path`.
changelog: --pretty now behaves more sensibly This actually just kind of fell out of the migration off of Clap as a result of treating `-p/--pretty` more rigorously as an alias for `--line-number --heading --color always`. Fixes #2381, Closes #2637
2023-11-22 01:03:06 +02:00
* [BUG #2381](https://github.com/BurntSushi/ripgrep/issues/2381):
Make `-p/--pretty` override flags like `--no-line-number`.
ignore: improve 'excludesFile' parsing This permits the value to be surrounded in double quotes. It's still not perfect, but probably better than it was. Getting this to be more correct will likely require writing (or using) a real parser, which I'm not particularly incliend to do at present. Fixes #2392, Closes #2629
2023-10-14 07:49:21 +02:00
* [BUG #2392](https://github.com/BurntSushi/ripgrep/issues/2392):
Improve global git config parsing of the `excludesFile` field.
doc: improve --sort=path This clarifies that the paths are not sorted in a fully lexicographic order, but that / is treated specially. Fixes #2418
2023-11-22 23:51:18 +02:00
* [BUG #2418](https://github.com/BurntSushi/ripgrep/pull/2418):
Clarify sorting semantics of `--sort=path`.
printer: trim before applying max column windowing Previously, we were applying the -M/--max-columns flag *before* triming prefix ASCII whitespace. But this doesn't make a whole lot of sense. We should be trimming first, but the result of trimming is ultimately what we'll be printing and that's what -M/--max-columns should be applied to. Fixes #2458
2023-11-22 23:04:26 +02:00
* [BUG #2458](https://github.com/BurntSushi/ripgrep/pull/2458):
Make `--trim` run before `-M/--max-columns` takes effect.
doc: add docs about .ignore/.rgignore in parent directories Closes #2479
2023-11-22 03:18:22 +02:00
* [BUG #2479](https://github.com/BurntSushi/ripgrep/issues/2479):
Add documentation about `.ignore`/`.rgignore` files in parent directories.
test: test that regex inline flags work as intended This was originally fixed by using non-capturing groups when joining patterns in crates/core/args.rs, but before that landed, it ended up getting fixed via a refactor in the course of migrating to regex 1.9. Namely, it's now fixed by pushing pattern joining down into the regex layer, so that patterns can be joined in the most effective way possible. Still, #2488 contains a useful test, so we bring that in here. The test actually failed for `rg -e ')('`, since it expected the command to fail with a syntax error. But my refactor actually causes this command to succeed. And indeed, #2488 worked around this by special casing a single pattern. That work-around fixes it for the single pattern case, but doesn't fix it for the -w or -X or multi-pattern case. So for now, we're content to leave well enough alone. The only real way to fix this for real is to parse each regexp individual and verify that each is valid on its own. It's not clear that doing so is worth it. Fixes #2480, Closes #2488
2023-04-13 07:28:16 +02:00
* [BUG #2480](https://github.com/BurntSushi/ripgrep/issues/2480):
Fix bug when using inline regex flags with `-e/--regexp`.
changelog: mention --field-match-separator bug fix This was probably fixed in the migration off of Clap. Closes #2519
2023-11-22 03:08:39 +02:00
* [BUG #2519](https://github.com/BurntSushi/ripgrep/issues/2519):
Fix incorrect default value in documentation for `--field-match-separator`.
cli: make resolve_binary take COM executables into account When `resolve_binary()` attempts to resolve a path to a program on Windows while searching for a program in `PATH` without an extension, `ripgrep` will assume the extension of the file to be `.exe` as it's the *de facto* standard, which will work most (99.99%) of the time... ...unless the binary is a COM executable (we're on Windows, duh). Closes #2523
2023-05-30 02:08:06 +02:00
* [BUG #2523](https://github.com/BurntSushi/ripgrep/issues/2523):
Make executable searching take `.com` into account on Windows.
regex: fix fast path for -w/--word-regexp flag (#2576) It turns out our fast path for -w/--word-regexp wasn't quite correct in some cases. Namely, we use `(?m:^|\W)(<original-regex>)(?m:\W|$)` as the implementation of -w/--word-regexp since `\b(<original-regex>)\b` has some unintuitive results in certain cases, specifically when <original-regex> matches non-word characters at match boundaries. The problem is that using this formulation means that you need to extract the capture group around <original-regex> to find the "real" match, since the surrounding (^|\W) and (\W|$) aren't part of the match. This is fine, but the capture group engine is usually slow, so we have a fast path where we try to deduce the correct match boundary after an initial match (before running capture groups). The problem is that doing this is rather tricky because it's hard to know, in general, whether the `^` or the `\W` matched. This still doesn't seem quite right overall, but we at least fix one more case. Fixes #2574
2023-07-31 14:51:09 +02:00
* [BUG #2574](https://github.com/BurntSushi/ripgrep/issues/2574):
Fix bug in `-w/--word-regexp` that would result in incorrect match offsets.
changelog: add another note about -w/--word-regexp bugs This was fixed a few commits ago when we updated to regex-automata 0.4 (regex 1.10). Fixes #2623
2023-10-10 02:06:27 +02:00
* [BUG #2623](https://github.com/BurntSushi/ripgrep/issues/2623):
Fix a number of bugs with the `-w/--word-regexp` flag.
ci: strip release binaries on macOS We were purportedly doing this already, but actually weren't because of confusion in the `if` condition. Closes #2636
2023-11-22 00:57:14 +02:00
* [BUG #2636](https://github.com/BurntSushi/ripgrep/pull/2636):
Strip release binaries for macOS.
regex: update regression test Sadly, PCRE2 has different behavior (but doesn't panic). We should look into that, but for now, this is good enough. Also, update the CHANGELOG. Ref #1891
2021-06-12 22:22:30 +02:00
doc: improve -r/--replace flag syntax docs Fixes #2108, Closes #2123
2022-01-12 12:18:20 +02:00
changelog: final prep before ripgrep 13 release
2021-06-12 14:11:51 +02:00
13.0.0 (2021-06-12)
===================
changelog: prep for ripgrep 13 release
2021-06-01 02:56:57 +02:00
ripgrep 13 is a new major version release of ripgrep that primarily contains
changelog: final prep before ripgrep 13 release
2021-06-12 14:11:51 +02:00
bug fixes, some performance improvements and a few minor breaking changes.
There is also a fix for a security vulnerability on Windows
([CVE-2021-3013](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3013)).
Some highlights:
changelog: prep for ripgrep 13 release
2021-06-01 02:56:57 +02:00
A new short flag, `-.`, has been added. It is an alias for the `--hidden` flag,
which instructs ripgrep to search hidden files and directories.
changelog: fix typo and add Ruby to type improvement list
2021-06-01 17:57:02 +02:00
ripgrep is now using a new
changelog: prep for ripgrep 13 release
2021-06-01 02:56:57 +02:00
[vectorized implementation of `memmem`](https://github.com/BurntSushi/memchr/pull/82),
changelog: a bit of polish I think I'm just waiting on the CVE to be published at this point.
2021-06-01 12:59:06 +02:00
which accelerates many common searches. If you notice any performance
regressions (or major improvements), I'd love to hear about them through an
issue report!
Also, for Windows users targeting MSVC, Cargo will now build fully static
executables of ripgrep. The release binaries for ripgrep 13 have been compiled
using this configuration.
changelog: add empty TBD section to CHANGELOG And update the release checklist to mention this process.
2020-05-29 15:49:45 +02:00
cli: add -. as short option for --hidden This is somewhat non-standard, but it seems nice on the surface: short flag names are in short supply, --hidden is probably somewhat common and -. has an obvious connection with how hidden files are named on Unix. Closes #1680
2020-09-11 01:32:54 +02:00
**BREAKING CHANGES**:
printer: vimgrep now only prints one line It turns out that the vimgrep format really only wants one line per match, even when that match spans multiple lines. We continue to support the previous behavior (print all lines in a match) in the `grep-printer` crate. We add a new option to enable the "only print the first line" behavior, and unconditionally enable it in ripgrep. We can do that because the option has no effect in single-line mode, since, well, in that case matches are guaranteed to span one line anyway. Fixes #1866
2021-05-31 03:36:35 +02:00
**Binary detection output has changed slightly.**
printer: tweak binary detection message format This roughly matches similar changes made in GNU grep recently.
2020-11-02 17:37:49 +02:00
In this release, a small tweak has been made to the output format when a binary
file is detected. Previously, it looked like this:
```
Binary file FOO matches (found "\0" byte around offset XXX)
```
Now it looks like this:
```
FOO: binary file matches (found "\0" byte around offset XXX)
```
printer: vimgrep now only prints one line It turns out that the vimgrep format really only wants one line per match, even when that match spans multiple lines. We continue to support the previous behavior (print all lines in a match) in the `grep-printer` crate. We add a new option to enable the "only print the first line" behavior, and unconditionally enable it in ripgrep. We can do that because the option has no effect in single-line mode, since, well, in that case matches are guaranteed to span one line anyway. Fixes #1866
2021-05-31 03:36:35 +02:00
**vimgrep output in multi-line now only prints the first line for each match.**
See [issue 1866](https://github.com/BurntSushi/ripgrep/issues/1866) for more
discussion on this. Previously, every line in a match was duplicated, even
when it spanned multiple lines. There are no changes to vimgrep output when
multi-line mode is disabled.
grep: fix bugs in handling multi-line look-around This commit hacks in a bug fix for handling look-around across multiple lines. The main problem is that by the time the matching lines are sent to the printer, the surrounding context---which some look-behind or look-ahead might have matched---could have been dropped if it wasn't part of the set of matching lines. Therefore, when the printer re-runs the regex engine in some cases (to do replacements, color matches, etc etc), it won't be guaranteed to see the same matches that the searcher found. Overall, this is a giant clusterfuck and suggests that the way I divided the abstraction boundary between the printer and the searcher is just wrong. It's likely that the searcher needs to handle more of the work of matching and pass that info on to the printer. The tricky part is that this additional work isn't always needed. Ultimately, this means a serious re-design of the interface between searching and printing. Sigh. The way this fix works is to smuggle the underlying buffer used by the searcher through into the printer. Since these bugs only impact multi-line search (otherwise, searches are only limited to matches across a single line), and since multi-line search always requires having the entire file contents in a single contiguous slice (memory mapped or on the heap), it follows that the buffer we pass through when we need it is, in fact, the entire haystack. So this commit refactors the printer's regex searching to use that buffer instead of the intended bundle of bytes containing just the relevant matching portions of that same buffer. There is one last little hiccup: PCRE2 doesn't seem to have a way to specify an ending position for a search. So when we re-run the search to find matches, we can't say, "but don't search past here." Since the buffer is likely to contain the entire file, we really cannot do anything here other than specify a fixed upper bound on the number of bytes to search. So if look-ahead goes more than N bytes beyond the match, this code will break by simply being unable to find the match. In practice, this is probably pretty rare. I believe that if we did a better fix for this bug by fixing the interfaces, then we'd probably try to have PCRE2 find the pertinent matches up front so that it never needs to re-discover them. Fixes #1412
2021-05-31 14:29:01 +02:00
**In multi-line mode, --count is now equivalent to --count-matches.**
This appears to match how `pcre2grep` implements `--count`. Previously, ripgrep
would produce outright incorrect counts. Another alternative would be to simply
count the number of lines---even if it's more than the number of matches---but
that seems highly unintuitive.
changelog: a bit of polish I think I'm just waiting on the CVE to be published at this point.
2021-06-01 12:59:06 +02:00
**FULL LIST OF FIXES AND IMPROVEMENTS:**
cli: fix arbitrary execution of program bug This fixes a bug only present on Windows that would permit someone to execute an arbitrary program if they crafted an appropriate directory tree. Namely, if someone put an executable named 'xz.exe' in the root of a directory tree and one ran 'rg -z foo' from the root of that tree, then the 'xz.exe' executable in that tree would execute if there are any 'xz' files anywhere in the tree. The root cause of this problem is that 'CreateProcess' on Windows will implicitly look in the current working directory for an executable when it is given a relative path to a program. Rust's standard library allows this behavior to occur, so we work around it here. We work around it by explicitly resolving programs like 'xz' via 'PATH'. That way, we only ever pass an absolute path to 'CreateProcess', which avoids the implicit behavior of checking the current working directory. This fix doesn't apply to non-Windows systems as it is believed to only impact Windows. In theory, the bug could apply on Unix if '.' is in one's PATH, but at that point, you reap what you sow. While the extent to which this is a security problem isn't clear, I think users generally expect to be able to download or clone repositories from the Internet and run ripgrep on them without fear of anything too awful happening. Being able to execute an arbitrary program probably violates that expectation. Therefore, CVE-2021-3013[1] was created for this issue. We apply the same logic to the --pre command, since the --pre command is likely in a user's config file and it would be surprising for something that the user is searching to modify which preprocessor command is used. The --pre and -z/--search-zip flags are the only two ways that ripgrep will invoke external programs, so this should cover any possible exploitable cases of this bug. [1] - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3013
2021-01-11 20:44:07 +02:00
Security fixes:
* [CVE-2021-3013](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3013):
Fixes a security hole on Windows where running ripgrep with either the
`-z/--search-zip` or `--pre` flags can result in running arbitrary
executables from the current directory.
doc: add vulnerability report docs Fixes #1773
2021-05-29 15:53:18 +02:00
* [VULN #1773](https://github.com/BurntSushi/ripgrep/issues/1773):
This is the public facing issue tracking CVE-2021-3013. ripgrep's README
now contains a section describing how to report a vulnerability.
cli: fix arbitrary execution of program bug This fixes a bug only present on Windows that would permit someone to execute an arbitrary program if they crafted an appropriate directory tree. Namely, if someone put an executable named 'xz.exe' in the root of a directory tree and one ran 'rg -z foo' from the root of that tree, then the 'xz.exe' executable in that tree would execute if there are any 'xz' files anywhere in the tree. The root cause of this problem is that 'CreateProcess' on Windows will implicitly look in the current working directory for an executable when it is given a relative path to a program. Rust's standard library allows this behavior to occur, so we work around it here. We work around it by explicitly resolving programs like 'xz' via 'PATH'. That way, we only ever pass an absolute path to 'CreateProcess', which avoids the implicit behavior of checking the current working directory. This fix doesn't apply to non-Windows systems as it is believed to only impact Windows. In theory, the bug could apply on Unix if '.' is in one's PATH, but at that point, you reap what you sow. While the extent to which this is a security problem isn't clear, I think users generally expect to be able to download or clone repositories from the Internet and run ripgrep on them without fear of anything too awful happening. Being able to execute an arbitrary program probably violates that expectation. Therefore, CVE-2021-3013[1] was created for this issue. We apply the same logic to the --pre command, since the --pre command is likely in a user's config file and it would be surprising for something that the user is searching to modify which preprocessor command is used. The --pre and -z/--search-zip flags are the only two ways that ripgrep will invoke external programs, so this should cover any possible exploitable cases of this bug. [1] - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3013
2021-01-11 20:44:07 +02:00
ignore: check ignore rules before issuing stat calls This seems like an obvious optimization but becomes critical when filesystem operations even as simple as stat can result in significant overheads; an example of this was a bespoke filesystem layer in Windows that hosted files remotely and would download them on-demand when particular filesystem operations occurred. Users of this system who ensured correct file-type fileters were being used could still get unnecessary file access resulting in large downloads. Fixes #1657, Closes #1660
2020-08-17 01:08:31 +02:00
Performance improvements:
* [PERF #1657](https://github.com/BurntSushi/ripgrep/discussions/1657):
Check if a file should be ignored first before issuing stat calls.
changelog: prep for ripgrep 13 release
2021-06-01 02:56:57 +02:00
* [PERF memchr#82](https://github.com/BurntSushi/memchr/pull/82):
ripgrep now uses a new vectorized implementation of `memmem`.
ignore: check ignore rules before issuing stat calls This seems like an obvious optimization but becomes critical when filesystem operations even as simple as stat can result in significant overheads; an example of this was a bespoke filesystem layer in Windows that hosted files remotely and would download them on-demand when particular filesystem operations occurred. Users of this system who ensured correct file-type fileters were being used could still get unnecessary file access resulting in large downloads. Fixes #1657, Closes #1660
2020-08-17 01:08:31 +02:00
changelog: sync with commits since last release I'm hoping to get a release out soon, and this is the first step.
2021-05-29 14:26:46 +02:00
Feature enhancements:
ignore/types: replace duplicate glob with *.aspx.vb *.aspx.cs was listed twice and the VB variant is missing. Closes #1683
2020-09-19 23:24:18 +02:00
* Added or improved file type filtering for ASP, Bazel, dvc, FlatBuffers,
changelog: fix typo and add Ruby to type improvement list
2021-06-01 17:57:02 +02:00
Futhark, minified files, Mint, pofiles (from GNU gettext) Racket, Red, Ruby,
VCL, Yang.
cli: print warning if nothing was searched This was once part of ripgrep, but at some point, was unintentionally removed. The value of this warning is that since ripgrep tries to be "smart" by default, it can be surprising if it doesn't search certain things. This warning covers the case when ripgrep searches *nothing*, which happens somewhat more frequently than you might expect. e.g., If you're searching within an ignore directory. Note that for now, we only print this message when the user has not supplied any explicit paths. It's not clear that we want to print this otherwise, and in particular, it seems that the message shows up too eagerly. e.g., 'rg foo does-not-exist' will both print an error about 'does-not-exist' not existing, *and* the message about no files being searched, which seems annoying in this case. We can always refine this logic later. Fixes #1404, Closes #1762
2020-12-15 09:59:55 +02:00
* [FEATURE #1404](https://github.com/BurntSushi/ripgrep/pull/1404):
ripgrep now prints a warning if nothing is searched.
cargo: statically link binary on Windows/MSVC Before this change, rg.exe depended on vcruntime140.dll, which does not exist on a fresh install of Windows. Closes #1613
2020-06-09 23:18:49 +02:00
* [FEATURE #1613](https://github.com/BurntSushi/ripgrep/pull/1613):
Cargo will now produce static executables on Windows when using MSVC.
cli: add -. as short option for --hidden This is somewhat non-standard, but it seems nice on the surface: short flag names are in short supply, --hidden is probably somewhat common and -. has an obvious connection with how hidden files are named on Unix. Closes #1680
2020-09-11 01:32:54 +02:00
* [FEATURE #1680](https://github.com/BurntSushi/ripgrep/pull/1680):
Add `-.` as a short flag alias for `--hidden`.
cli: add --field-{context,match}-separator flags These flags permit configuring the bytes used to delimit fields in match or context lines, where "fields" are things like the file path, line number, column number and the match/context itself. Fixes #1842, Closes #1871
2021-05-26 03:41:11 +02:00
* [FEATURE #1842](https://github.com/BurntSushi/ripgrep/issues/1842):
Add `--field-{context,match}-separator` for customizing field delimiters.
cli: print warning if nothing was searched This was once part of ripgrep, but at some point, was unintentionally removed. The value of this warning is that since ripgrep tries to be "smart" by default, it can be surprising if it doesn't search certain things. This warning covers the case when ripgrep searches *nothing*, which happens somewhat more frequently than you might expect. e.g., If you're searching within an ignore directory. Note that for now, we only print this message when the user has not supplied any explicit paths. It's not clear that we want to print this otherwise, and in particular, it seems that the message shows up too eagerly. e.g., 'rg foo does-not-exist' will both print an error about 'does-not-exist' not existing, *and* the message about no files being searched, which seems annoying in this case. We can always refine this logic later. Fixes #1404, Closes #1762
2020-12-15 09:59:55 +02:00
* [FEATURE #1856](https://github.com/BurntSushi/ripgrep/pull/1856):
changelog: sync with commits since last release I'm hoping to get a release out soon, and this is the first step.
2021-05-29 14:26:46 +02:00
The README now links to a
[Spanish translation](https://github.com/UltiRequiem/traducciones/tree/master/ripgrep).
doc: document cygwin path translation behavior Kudos to @Pyker for posting more details about this. Closes #1277
2020-09-13 15:29:28 +02:00
Bug fixes:
* [BUG #1277](https://github.com/BurntSushi/ripgrep/issues/1277):
Document cygwin path translation behavior in the FAQ.
printer: trim line terminator before doing replacements This is basically the same bug as #1401, but applied to replacements instead of --only-matching. Fixes #1739
2021-06-01 01:52:26 +02:00
* [BUG #1739](https://github.com/BurntSushi/ripgrep/issues/1739):
Fix bug where replacements were buggy if the regex matched a line terminator.
printer: fix multi-line replacement bug This commit fixes a subtle bug in multi-line replacement of line terminators. The problem is that even though ripgrep supports multi-line searches, it is *still* line oriented. It still needs to print line numbers, for example. For this reason, there are various parts in the printer that iterate over lines in order to format them into the desired output. This turns out to be problematic in some cases. #1311 documents one of those cases (with line numbers enabled to highlight a point later): $ printf "hello\nworld\n" | rg -n -U "\n" -r "?" 1:hello? 2:world? But the desired output is this: $ printf "hello\nworld\n" | rg -n -U "\n" -r "?" 1:hello?world? At first I had thought that the main problem was that the printer was taking ownership of writing line terminators, even if the input already had them. But it's more subtle than that. If we fix that issue, we get output like this instead: $ printf "hello\nworld\n" | rg -n -U "\n" -r "?" 1:hello?2:world? Notice how '2:' is printed before 'world?'. The reason it works this way is because matches are reported to the printer in a line oriented way. That is, the printer gets a block of lines. The searcher guarantees that all matches that start or end in any of those lines also end or start in another line in that same block. As a result, the printer uses this assumption: once it has processed a block of lines, the next match will begin on a new and distinct line. Thus, things like '2:' are printed. This is generally all fine and good, but an impedance mismatch arises when replacements are used. Because now, the replacement can be used to change the "block of lines" approach. Now, in terms of the output, the subsequent match might actually continue the current line since the replacement might get rid of the concept of lines altogether. We can sometimes work around this. For example: $ printf "hello\nworld\n" | rg -U "\n(.)?" -r '?$1' hello?world? Why does this work? It's because the '(.)' after the '\n' causes the match to overlap between lines. Thus, the searcher guarantees that the block sent to the printer contains every line. And there in lay the solution: all we need to do is tweak the multi-line searcher so that it combines lines with matches that directly adjacent, instead of requiring at least one byte of overlap. Fixing that solves the issue above. It does cause some tests to fail: * The binary3 test in the searcher crate fails because adjacent line matches are now one part of block, and that block is scanned for binary data. To preserve the essence of the test, we insert a couple dummy lines to split up the blocks. * The JSON CRLF test. It was testing that we didn't output any messages with an empty 'submatches' array. That is indeed still the case. The difference is that the messages got combined because of the adjacent line merging behavior. This is a slight change to the output, but is still correct. Fixes #1311
2021-05-31 12:10:48 +02:00
* [BUG #1311](https://github.com/BurntSushi/ripgrep/issues/1311):
Fix multi-line bug where a search & replace for `\n` didn't work as expected.
printer: trim line terminator before finding submatches This fixes a bug where PCRE2 look-around could change the result of a match if it observed a line terminator in the printer. And in particular, this is precisely how the searcher operates: the line is considered unto itself *without* the line terminator. Fixes #1401
2021-06-01 01:00:56 +02:00
* [BUG #1401](https://github.com/BurntSushi/ripgrep/issues/1401):
Fix buggy interaction between PCRE2 look-around and `-o/--only-matching`.
grep: fix bugs in handling multi-line look-around This commit hacks in a bug fix for handling look-around across multiple lines. The main problem is that by the time the matching lines are sent to the printer, the surrounding context---which some look-behind or look-ahead might have matched---could have been dropped if it wasn't part of the set of matching lines. Therefore, when the printer re-runs the regex engine in some cases (to do replacements, color matches, etc etc), it won't be guaranteed to see the same matches that the searcher found. Overall, this is a giant clusterfuck and suggests that the way I divided the abstraction boundary between the printer and the searcher is just wrong. It's likely that the searcher needs to handle more of the work of matching and pass that info on to the printer. The tricky part is that this additional work isn't always needed. Ultimately, this means a serious re-design of the interface between searching and printing. Sigh. The way this fix works is to smuggle the underlying buffer used by the searcher through into the printer. Since these bugs only impact multi-line search (otherwise, searches are only limited to matches across a single line), and since multi-line search always requires having the entire file contents in a single contiguous slice (memory mapped or on the heap), it follows that the buffer we pass through when we need it is, in fact, the entire haystack. So this commit refactors the printer's regex searching to use that buffer instead of the intended bundle of bytes containing just the relevant matching portions of that same buffer. There is one last little hiccup: PCRE2 doesn't seem to have a way to specify an ending position for a search. So when we re-run the search to find matches, we can't say, "but don't search past here." Since the buffer is likely to contain the entire file, we really cannot do anything here other than specify a fixed upper bound on the number of bytes to search. So if look-ahead goes more than N bytes beyond the match, this code will break by simply being unable to find the match. In practice, this is probably pretty rare. I believe that if we did a better fix for this bug by fixing the interfaces, then we'd probably try to have PCRE2 find the pertinent matches up front so that it never needs to re-discover them. Fixes #1412
2021-05-31 14:29:01 +02:00
* [BUG #1412](https://github.com/BurntSushi/ripgrep/issues/1412):
Fix multi-line bug with searches using look-around past matching lines.
changelog: fish completions are staying In a previous release, I announced that Fish completions were being removed. But the Fish project decided to remove theirs and have ripgrep's stay. Closes #1577
2021-06-01 01:39:20 +02:00
* [BUG #1577](https://github.com/BurntSushi/ripgrep/issues/1577):
Fish shell completions will continue to be auto-generated.
printer: fix context bug when --max-count is used In the case where after-context is requested with a match count limit, we need to be careful not to reset the state tracking the remaining context lines. Fixes #1380, Closes #1642
2020-07-11 12:42:54 +02:00
* [BUG #1642](https://github.com/BurntSushi/ripgrep/issues/1642):
Fixes a bug where using `-m` and `-A` printed more matches than the limit.
changelog: sync with commits since last release I'm hoping to get a release out soon, and this is the first step.
2021-05-29 14:26:46 +02:00
* [BUG #1703](https://github.com/BurntSushi/ripgrep/issues/1703):
Clarify the function of `-u/--unrestricted`.
* [BUG #1708](https://github.com/BurntSushi/ripgrep/issues/1708):
Clarify how `-S/--smart-case` works.
* [BUG #1730](https://github.com/BurntSushi/ripgrep/issues/1730):
Clarify that CLI invocation must always be valid, regardless of config file.
cli: fix stdin detection for Powershell on Unix It seems that PowerShell uses sockets instead of FIFOs to redirect the output between commands. So add `is_socket` to our `is_readable_stdin` check. This seems unlikely to cause problems and it probably more generally correct than what we had before. In theory, it could cause problems if it produces false positives, in which case, ripgrep will try to read stdin when it should search the current working directory. (And this usually winds up manifesting as ripgrep blocking forever.) But, if the stdin handle reports itself as a socket, then it seems like we should read it. Fixes #1741, Closes #1742
2020-11-23 08:25:20 +02:00
* [BUG #1741](https://github.com/BurntSushi/ripgrep/issues/1741):
Fix stdin detection when using PowerShell in UNIX environments.
globset: fix recursive suffix over matching Previous, 'foo/**' would match 'foo', but it shouldn't have. In this case, not matching 'foo' is what is documented and also seems consistent with other recursive globbing implementations (like that in zsh). This also updates the prefix extractor to pull 'foo/' out of 'foo/**'. Closes #1756
2020-12-08 06:49:29 +02:00
* [BUG #1756](https://github.com/BurntSushi/ripgrep/pull/1756):
Fix bug where `foo/**` would match `foo`, but it shouldn't.
printer: fix \r\n line terminator handling This fixes a bug where it was assumed that 'is_suffix' when CRLF handling was enabled mean that '\r\n' was present. But that's not the case, and it is intentional that 'is_suffix' only looks for '\n'. (Which is why #1803 wasn't taken, which tries to fix this by changing 'is_suffix'.) Fixes #1765, Closes #1803
2021-05-30 17:13:27 +02:00
* [BUG #1765](https://github.com/BurntSushi/ripgrep/issues/1765):
Fix panic when `--crlf` is used in some cases.
searcher: do UTF-8 BOM sniffing like UTF-16 Previously, we were only looking for the UTF-16 BOM for determining whether to do transcoding or not. But we should also look for the UTF-8 BOM as well. Fixes #1638, Closes #1697
2020-10-02 22:17:39 +02:00
* [BUG #1638](https://github.com/BurntSushi/ripgrep/issues/1638):
Correctly sniff UTF-8 and do transcoding, like we do for UTF-16.
doc: document '{a,b}' glob syntax This syntax does not exist in `git`, so it is not documented in `man gitignore`. There is a question of whether it *should* exist, but as long as it does, it should be documented somewhere. See also: https://github.com/BurntSushi/ripgrep/issues/1221 https://github.com/BurntSushi/ripgrep/issues/1368 Closes #1816
2021-03-10 00:12:15 +02:00
* [BUG #1816](https://github.com/BurntSushi/ripgrep/issues/1816):
Add documentation for glob alternate syntax, e.g., `{a,b,..}`.
changelog: sync with commits since last release I'm hoping to get a release out soon, and this is the first step.
2021-05-29 14:26:46 +02:00
* [BUG #1847](https://github.com/BurntSushi/ripgrep/issues/1847):
Clarify how the `--hidden` flag works.
printer: fix --vimgrep for multi-line mode It turned out that --vimgrep wasn't quite getting the column of each match correctly. Instead of printing column numbers relative to the current line, it was printing column numbers as byte offsets relative to where the match began. To fix this, we simply subtract the offset of the line number from the beginning of the match. If the beginning of the match came before the start of the current line, then there's really nothing sensible we can do other than to use a column number of 1, which we now document. Interestingly, existing tests were checking that the previous behavior was intended. My only defense is that I somehow tricked myself into thinking it was a byte offset instead of a column number. Kudos to @bfrg for calling this out in #1866: https://github.com/BurntSushi/ripgrep/issues/1866#issuecomment-841635553
2021-05-15 14:23:01 +02:00
* [BUG #1866](https://github.com/BurntSushi/ripgrep/issues/1866#issuecomment-841635553):
Fix bug when computing column numbers in `--vimgrep` mode.
args: make --passthru and -A/-B/-C override each other Fixes #1868
2021-05-29 17:56:43 +02:00
* [BUG #1868](https://github.com/BurntSushi/ripgrep/issues/1868):
Fix bug where `--passthru` and `-A/-B/-C` did not override each other.
doc: clarify --files-with-matches and --files-without-match Ref https://github.com/BurntSushi/ripgrep/issues/103#issuecomment-763083510 Closes #1869
2021-05-25 14:04:45 +02:00
* [BUG #1869](https://github.com/BurntSushi/ripgrep/pull/1869):
Clarify docs for `--files-with-matches` and `--files-without-match`.
impl: fix --multiline anchored match bug This fixes a bug where using \A or (?-m)^ in combination with -U/--multiline would permit matches that aren't anchored to the beginning of the file. The underlying cause was an optimization that occurred when mmaps couldn't be used. Namely, ripgrep tries to still read the input incrementally if it knows the pattern can't match through a new line. But the detection logic was flawed, since it didn't account for line anchors. This commit fixes that. Fixes #1878, Fixes #1879
2021-05-29 13:34:14 +02:00
* [BUG #1878](https://github.com/BurntSushi/ripgrep/issues/1878):
Fix bug where `\A` could produce unanchored matches in multiline search.
changelog: sync with commits since last release I'm hoping to get a release out soon, and this is the first step.
2021-05-29 14:26:46 +02:00
* [BUG 94e4b8e3](https://github.com/BurntSushi/ripgrep/commit/94e4b8e3):
Fix column numbers with `--vimgrep` is used with `-U/--multiline`.
doc: document cygwin path translation behavior Kudos to @Pyker for posting more details about this. Closes #1277
2020-09-13 15:29:28 +02:00
changelog: add empty TBD section to CHANGELOG And update the release checklist to mention this process.
2020-05-29 15:49:45 +02:00
changelog: 12.1.1
2020-05-29 15:26:33 +02:00
12.1.1 (2020-05-29)
===================
ripgrep 12.1.1 is a patch release that fixes a couple small bugs. In
particular, the ripgrep 12.1.0 release did not tag new releases for all of its
in-tree dependencies. As a result, ripgrep built dependencies from crates.io
would produce a different build than compiling ripgrep from source on the
`12.1.0` tag. Namely, some crates like `grep-cli` had unreleased changes.
doc: fix egregious markup output We use '+++' syntax to output a literal '**' for a '--glob' example. This '+++' syntax is pretty ugly when rendered literally via --help. We fix this by hackily inserting the '+++' syntax for its one specific case that we need it during man page generation. Not ideal but it works. And --help still has some '*foo*' markup, but we live with that for now. Fixes #1581
2020-05-13 14:13:05 +02:00
Bug fixes:
* [BUG #1581](https://github.com/BurntSushi/ripgrep/issues/1581):
Corrects some egregious markup output in `--help`.
doc: clarify capture group indices And in particular, note the special $0 index, which corresponds to the entire match. Fixes #1591
2020-05-22 04:22:51 +02:00
* [BUG #1591](https://github.com/BurntSushi/ripgrep/issues/1591):
Mention the special `$0` capture group in docs for the `-r/--replace` flag.
changelog: 12.1.1
2020-05-29 15:26:33 +02:00
* [BUG #1602](https://github.com/BurntSushi/ripgrep/issues/1602):
Fix failing test resulting from out-of-sync dependencies.
doc: fix egregious markup output We use '+++' syntax to output a literal '**' for a '--glob' example. This '+++' syntax is pretty ugly when rendered literally via --help. We fix this by hackily inserting the '+++' syntax for its one specific case that we need it during man page generation. Not ideal but it works. And --help still has some '*foo*' markup, but we live with that for now. Fixes #1581
2020-05-13 14:13:05 +02:00
changelog: 12.1.0
2020-05-09 17:36:44 +02:00
12.1.0 (2020-05-09)
===================
changelog: add downstream notices
2020-05-09 04:57:58 +02:00
ripgrep 12.1.0 is a small minor version release that mostly includes bug fixes
changelog: 12.1.0
2020-05-09 17:36:44 +02:00
and documentation improvements. This release also contains some important
notices for downstream packagers.
changelog: add downstream notices
2020-05-09 04:57:58 +02:00
**Notices for downstream ripgrep package maintainers:**
* Fish shell completions will be removed in the ripgrep 13 release.
See [#1577](https://github.com/BurntSushi/ripgrep/issues/1577)
for more details.
* ripgrep has switched from `a2x` to `asciidoctor` to generate the man page.
If `asciidoctor` is not present, then ripgrep will currently fall back to
`a2x`. Support for `a2x` will be dropped in the ripgrep 13 release.
See [#1544](https://github.com/BurntSushi/ripgrep/issues/1544)
for more details.
grep-cli: support files compressed by compress(1) While Linux distributions (at least Arch Linux, RHEL, Debian) do not support compressing files with compress(1), macOS & AIX do (the utility is part of POSIX). Additionally, gzip is able to uncompress such compressed files and provides an `uncompress` binary. Closes #1547
2020-04-10 11:19:25 +02:00
Feature enhancements:
* [FEATURE #1547](https://github.com/BurntSushi/ripgrep/pull/1547):
Support decompressing `.Z` files via `uncompress`.
regex: fix another inner literal bug It looks like `is_simple` wasn't quite correct. I can't wait until this code is rewritten. It is still not quite clearly correct to me. Fixes #1537
2020-04-02 02:34:39 +02:00
Bug fixes:
doc: add a section about --pre to the GUIDE Fixes #1252
2020-05-08 17:44:00 +02:00
* [BUG #1252](https://github.com/BurntSushi/ripgrep/issues/1252):
Add a section on the `--pre` flag to the GUIDE.
cli: improve invalid UTF-8 pattern error message When a pattern with invalid UTF-8 is given, the error message suggests unqualified use of hex escape sequences to match arbitrary bytes. But you *also* need to disable Unicode mode. So include that in the error message. Fixes #1339
2020-05-08 14:53:41 +02:00
* [BUG #1339](https://github.com/BurntSushi/ripgrep/issues/1339):
Improve error message when a pattern with invalid UTF-8 is provided.
doc: note how to escape a '$' in --replace Fixes #1524
2020-05-08 14:32:20 +02:00
* [BUG #1524](https://github.com/BurntSushi/ripgrep/issues/1524):
Note how to escape a `$` when using `--replace`.
regex: fix another inner literal bug It looks like `is_simple` wasn't quite correct. I can't wait until this code is rewritten. It is still not quite clearly correct to me. Fixes #1537
2020-04-02 02:34:39 +02:00
* [BUG #1537](https://github.com/BurntSushi/ripgrep/issues/1537):
Fix match bug caused by inner literal optimization.
doc: use asciidoctor instead of a2x AsciiDoc development is continued under asciidoctor. See https://github.com/asciidoc/asciidoc. We do however fallback to a2x if asciidoctor is not present. This is to ease migration, but at some point, it's likely that support for a2x will be dropped. Originally reported downstream: https://github.com/Homebrew/linuxbrew-core/issues/19885 Closes #1544
2020-04-06 15:05:17 +02:00
* [BUG #1544](https://github.com/BurntSushi/ripgrep/issues/1544):
ripgrep now uses `asciidoctor` instead of `a2x` to generate its man page.
changelog: add #1550 to CHANGELOG
2020-05-09 05:37:17 +02:00
* [BUG #1550](https://github.com/BurntSushi/ripgrep/issues/1550):
Substantially reduce peak memory usage when searching wide directories.
doc: add config file note for --type-{add,clear} This clarifies that persistence is possible via a configuration file. Fixes #1571
2020-05-08 14:18:33 +02:00
* [BUG #1571](https://github.com/BurntSushi/ripgrep/issues/1571):
Add note about configuration files in `--type-{add,clear}` docs.
printer: fix --count-matches output In order to implement --count-matches, we simply re-execute the regex on the spans reported by the searcher. The spans always correspond to the lines that participated in the match. This is the correct thing to do, except when the regex contains look-ahead (or look-behind). In particular, the look-around permits the regex's match success to depends on an arbitrary point before or after the lines actually reported as participating in the match. Since only the matched lines are reported to the printer, it is possible for subsequent searching on those lines to fail. A true fix for this would somehow make the total span available to the printer. But that seems tricky since it isn't always available. For PCRE2's case in multiline mode, it is available because we force it to be so for correctness. For now, we simply detect this corner case heuristically. If the match count is zero, then it necessarily means there is some kind of look-around that isn't matching. So we set the match count to 1. This is probably incorrect in some cases, although my brain can't quite come up with a concrete example. Nevertheless, this is strictly better than the status quo. Fixes #1573
2020-05-08 14:09:26 +02:00
* [BUG #1573](https://github.com/BurntSushi/ripgrep/issues/1573):
Fix incorrect `--count-matches` output when using look-around.
regex: fix another inner literal bug It looks like `is_simple` wasn't quite correct. I can't wait until this code is rewritten. It is still not quite clearly correct to me. Fixes #1537
2020-04-02 02:34:39 +02:00
changelog: prepare for 12.0.1 release
2020-03-30 00:47:46 +02:00
12.0.1 (2020-03-29)
===================
changelog: prepare for 12.0.1 release, redux
2020-03-30 00:50:31 +02:00
ripgrep 12.0.1 is a small patch release that includes a minor bug fix relating
to superfluous error messages when searching git repositories with sub-modules.
This was a regression introduced in the 12.0.0 release.
ignore: squash noisy error message We should not assume that the commondir file actually exists. If it doesn't, then just move on. This otherwise emits an error message when searching normal submodules, which is not OK. This regression was introduced in #1446. Fixes #1520
2020-03-17 00:47:46 +02:00
Bug fixes:
* [BUG #1520](https://github.com/BurntSushi/ripgrep/issues/1520):
Don't emit spurious error messages in git repositories with submodules.
changelog: prepare for 12.0.0 release
2020-03-16 02:51:03 +02:00
12.0.0 (2020-03-15)
===================
ripgrep 12 is a new major version release of ripgrep that contains many bug
fixes, several important performance improvements and a few minor new features.
In a near future release, I am hoping to add an
[indexing feature](https://github.com/BurntSushi/ripgrep/issues/1497)
to ripgrep, which will dramatically speed up searching by building an index.
Feedback would very much be appreciated, especially on the user experience
which will be difficult to get right.
This release has no known breaking changes.
changelog: update with bug fix
2019-08-02 13:37:27 +02:00
cli: add --no-unicode, deprecate --no-pcre2-unicode This adds a universal --no-unicode flag that is intended to work for all supported regex engines. There is no point in retaining --no-pcre2-unicode, so we make them aliases to the new flags and deprecate them.
2020-02-17 22:34:59 +02:00
Deprecations:
* The `--no-pcre2-unicode` flag is deprecated. Instead, use the `--no-unicode`
flag, which applies to both the default regex engine and PCRE2. For now,
`--no-pcre2-unicode` and `--pcre2-unicode` are aliases to `--no-unicode`
and `--unicode`, respectively. The `--[no-]pcre2-unicode` flags may be
removed in a future release.
cli: add engine flag This permits switching between the different regex engine modes that ripgrep supports. The purpose of this flag is to make it easier to extend ripgrep with additional regex engines. Closes #1488, Closes #1502
2020-02-27 17:58:56 +02:00
* The `--auto-hybrid-regex` flag is deprecated. Instead, use the new `--engine`
flag with the `auto` value.
cli: add --no-unicode, deprecate --no-pcre2-unicode This adds a universal --no-unicode flag that is intended to work for all supported regex engines. There is no point in retaining --no-pcre2-unicode, so we make them aliases to the new flags and deprecate them.
2020-02-17 22:34:59 +02:00
ignore: add existence check for ignore files This commit adds a simple `.exists()` check for `.gitignore`, `.ignore`, and other similar files before actually calling `File::open(…)` in `GitIgnoreBuilder::add`. The reason is that a simple existence check via `stat` can be faster than actually trying to `open` the file, see https://stackoverflow.com/a/12774387/704831. As we typically expect(?) the number of directories *without* ignore files to be much larger than the number of directories *with* ignore files, this leads to an overall speedup. The performance gain is not huge for `rg`, but can be quite significant if more `.gitignore`-like files are added via `add_custom_ignore_filename`. The speedup is *larger* for folders with *low* files-per-directory ratios. Note though that we do not do this check on Windows until a specific analysis there suggests this is beneficial. Namely, Windows generally has slower file system operations, so it's not clear whether this speculative check is actually a benefit or not. Benchmark results ----------------- `rg --files` in my home folder (200k results, 6.5 files per directory): | Command | Mean [ms] | Min [ms] | Max [ms] | Relative | |:---|---:|---:|---:|---:| | `./rg-master --files` | 396.4 ± 3.2 | 390.9 | 400.0 | 1.05 | | `./rg-feature --files` | 376.0 ± 3.6 | 369.3 | 383.5 | 1.00 | `rg --files --hidden` in my home folder (800k results, 5.4 files per directory) | Command | Mean [s] | Min [s] | Max [s] | Relative | |:---|---:|---:|---:|---:| | `./rg-master --files --hidden` | 1.575 ± 0.012 | 1.560 | 1.597 | 1.06 | | `./rg-feature --files --hidden` | 1.479 ± 0.011 | 1.464 | 1.496 | 1.00 | `rg --files` in the chromium-79.0.3915.2 source tree (300k results, 12.7 files per directory) | Command | Mean [ms] | Min [ms] | Max [ms] | Relative | |:---|---:|---:|---:|---:| | `~/rg-master --files` | 445.2 ± 5.3 | 435.6 | 453.0 | 1.04 | | `~/rg-feature --files` | 428.9 ± 7.0 | 418.2 | 440.0 | 1.00 | `rg --files` in the linux-5.3 source tree (65k results, 15.1 files per directory) | Command | Mean [ms] | Min [ms] | Max [ms] | Relative | |:---|---:|---:|---:|---:| | `./rg-master --files` | 94.5 ± 1.9 | 89.8 | 98.5 | 1.02 | | `./rg-feature --files` | 92.6 ± 2.7 | 88.4 | 98.7 | 1.00 | Closes #1381
2019-09-17 20:07:23 +02:00
Performance improvements:
regex: avoid using literal optimizations when whitespace is detected If a literal is entirely whitespace, then it's quite likely that it is very common. So when that case occurs, just don't do (inner) literal optimizations at all. The regex engine may still make sub-optimal decisions here, but that's a problem for another day. Fixes #1087
2020-03-15 18:01:42 +02:00
* [PERF #1087](https://github.com/BurntSushi/ripgrep/pull/1087):
ripgrep is smarter when detected literals are whitespace.
ignore: add existence check for ignore files This commit adds a simple `.exists()` check for `.gitignore`, `.ignore`, and other similar files before actually calling `File::open(…)` in `GitIgnoreBuilder::add`. The reason is that a simple existence check via `stat` can be faster than actually trying to `open` the file, see https://stackoverflow.com/a/12774387/704831. As we typically expect(?) the number of directories *without* ignore files to be much larger than the number of directories *with* ignore files, this leads to an overall speedup. The performance gain is not huge for `rg`, but can be quite significant if more `.gitignore`-like files are added via `add_custom_ignore_filename`. The speedup is *larger* for folders with *low* files-per-directory ratios. Note though that we do not do this check on Windows until a specific analysis there suggests this is beneficial. Namely, Windows generally has slower file system operations, so it's not clear whether this speculative check is actually a benefit or not. Benchmark results ----------------- `rg --files` in my home folder (200k results, 6.5 files per directory): | Command | Mean [ms] | Min [ms] | Max [ms] | Relative | |:---|---:|---:|---:|---:| | `./rg-master --files` | 396.4 ± 3.2 | 390.9 | 400.0 | 1.05 | | `./rg-feature --files` | 376.0 ± 3.6 | 369.3 | 383.5 | 1.00 | `rg --files --hidden` in my home folder (800k results, 5.4 files per directory) | Command | Mean [s] | Min [s] | Max [s] | Relative | |:---|---:|---:|---:|---:| | `./rg-master --files --hidden` | 1.575 ± 0.012 | 1.560 | 1.597 | 1.06 | | `./rg-feature --files --hidden` | 1.479 ± 0.011 | 1.464 | 1.496 | 1.00 | `rg --files` in the chromium-79.0.3915.2 source tree (300k results, 12.7 files per directory) | Command | Mean [ms] | Min [ms] | Max [ms] | Relative | |:---|---:|---:|---:|---:| | `~/rg-master --files` | 445.2 ± 5.3 | 435.6 | 453.0 | 1.04 | | `~/rg-feature --files` | 428.9 ± 7.0 | 418.2 | 440.0 | 1.00 | `rg --files` in the linux-5.3 source tree (65k results, 15.1 files per directory) | Command | Mean [ms] | Min [ms] | Max [ms] | Relative | |:---|---:|---:|---:|---:| | `./rg-master --files` | 94.5 ± 1.9 | 89.8 | 98.5 | 1.02 | | `./rg-feature --files` | 92.6 ± 2.7 | 88.4 | 98.7 | 1.00 | Closes #1381
2019-09-17 20:07:23 +02:00
* [PERF #1381](https://github.com/BurntSushi/ripgrep/pull/1381):
Directory traversal is sped up with speculative ignore-file existence checks.
changelog: add commit links ... now that we have stable identifiers.
2020-02-18 00:34:17 +02:00
* [PERF cd8ec38a](https://github.com/BurntSushi/ripgrep/commit/cd8ec38a):
grep-regex: improve inner literal detection This fixes an interesting performance bug where the inner literal extractor would sometimes choose a sub-optimal literal. For example, consider the regex: \x20+Sherlock Holmes\x20+ (The `\x20` is the ASCII code for a space character, which we use here to just make it clearer. It otherwise does not matter.) Previously, this would see the initial \x20 and then stop collecting literals after the `+` repetition operator. This was because the inner literal detector was adapter from the prefix literal detector, which had to stop here. Namely, while \x20S would be a valid prefix (for example), \x20\x20S would also be a valid prefix. As would \x20\x20\x20S and so on. So the prefix detector would have to stop at the repetition operator. Otherwise, only searching for \x20S could potentially scan farther then the starting position of the next match. However, for inner literals, this calculus no longer makes sense. We can freely search for, e.g., \x20S without missing matches that start with \x20\x20S precisely because we know this is an inner literal which may not correspond to the start of a match. With this fix, the literal that is now detected is \x20Sherlock Holmes\x20 Which is much better. We achieve this by no longer "cutting" literals after seeing a `+` repetition operator. Instead, we permit literals to continue to be extended. The reason why this is important is because using \x20 as the literal to search for is generally bad juju since it is so common. In fact, we should probably add more logic here to either avoid such things or give up entirely on the inner literal optimization if it detected a literal that we think is very common. But we punt on such things here.
2020-02-16 13:32:57 +02:00
Improve inner literal detection to cover more cases more effectively.
e.g., ` +Sherlock Holmes +` now has ` Sherlock Holmes ` extracted instead
of ` `.
changelog: add commit links ... now that we have stable identifiers.
2020-02-18 00:34:17 +02:00
* [PERF 6a0e0147](https://github.com/BurntSushi/ripgrep/commit/6a0e0147):
grep-regex: improve literal detection with -w When the -w/--word-regexp was used, ripgrep would in many cases fail to apply literal optimizations. This occurs specifically when the regex given by the user is an alternation of literals with no common prefixes or suffixes, e.g., rg -w 'foo|bar|baz|quux' In this case, the inner literal detector fails. Normally, this would result in literal prefixes being detected by the regex engine. But because of the -w/--word-regexp flag, the actual regex that we run ends up looking like this: (^|\W)(foo|bar|baz|quux)($|\W) which of course defeats any prefix or suffix literal optimizations in the regex crate's somewhat naive extractor. (A better extractor could still do literal optimizations in the above case.) So this commit fixes this by falling back to prefix or suffix literals when they're available instead of prematurely giving up and assuming the regex engine will do the rest.
2020-02-16 17:36:38 +02:00
Improve literal detection when the `-w/--word-regexp` flag is used.
changelog: add commit links ... now that we have stable identifiers.
2020-02-18 00:34:17 +02:00
* [PERF ad97e9c9](https://github.com/BurntSushi/ripgrep/commit/ad97e9c9):
grep-regex: add fast path for -w/--word-regexp Previously, ripgrep would always defer to the regex engine's capturing matches in order to implement word matching. Namely, ripgrep would determine the correct match offsets via a capturing group, since the word regex is itself generated from the user supplied regex. Unfortunately, the regex engine's capturing mode is still fairly slow, so this commit adds a fast path to avoid capturing mode in the vast majority of cases. See comments in the code for details.
2020-02-16 17:43:26 +02:00
Improve overall performance of the `-w/--word-regexp` flag.
ignore: add existence check for ignore files This commit adds a simple `.exists()` check for `.gitignore`, `.ignore`, and other similar files before actually calling `File::open(…)` in `GitIgnoreBuilder::add`. The reason is that a simple existence check via `stat` can be faster than actually trying to `open` the file, see https://stackoverflow.com/a/12774387/704831. As we typically expect(?) the number of directories *without* ignore files to be much larger than the number of directories *with* ignore files, this leads to an overall speedup. The performance gain is not huge for `rg`, but can be quite significant if more `.gitignore`-like files are added via `add_custom_ignore_filename`. The speedup is *larger* for folders with *low* files-per-directory ratios. Note though that we do not do this check on Windows until a specific analysis there suggests this is beneficial. Namely, Windows generally has slower file system operations, so it's not clear whether this speculative check is actually a benefit or not. Benchmark results ----------------- `rg --files` in my home folder (200k results, 6.5 files per directory): | Command | Mean [ms] | Min [ms] | Max [ms] | Relative | |:---|---:|---:|---:|---:| | `./rg-master --files` | 396.4 ± 3.2 | 390.9 | 400.0 | 1.05 | | `./rg-feature --files` | 376.0 ± 3.6 | 369.3 | 383.5 | 1.00 | `rg --files --hidden` in my home folder (800k results, 5.4 files per directory) | Command | Mean [s] | Min [s] | Max [s] | Relative | |:---|---:|---:|---:|---:| | `./rg-master --files --hidden` | 1.575 ± 0.012 | 1.560 | 1.597 | 1.06 | | `./rg-feature --files --hidden` | 1.479 ± 0.011 | 1.464 | 1.496 | 1.00 | `rg --files` in the chromium-79.0.3915.2 source tree (300k results, 12.7 files per directory) | Command | Mean [ms] | Min [ms] | Max [ms] | Relative | |:---|---:|---:|---:|---:| | `~/rg-master --files` | 445.2 ± 5.3 | 435.6 | 453.0 | 1.04 | | `~/rg-feature --files` | 428.9 ± 7.0 | 418.2 | 440.0 | 1.00 | `rg --files` in the linux-5.3 source tree (65k results, 15.1 files per directory) | Command | Mean [ms] | Min [ms] | Max [ms] | Relative | |:---|---:|---:|---:|---:| | `./rg-master --files` | 94.5 ± 1.9 | 89.8 | 98.5 | 1.02 | | `./rg-feature --files` | 92.6 ± 2.7 | 88.4 | 98.7 | 1.00 | Closes #1381
2019-09-17 20:07:23 +02:00
cli: add --no-context-separator flag --context-separator='' still adds a new line separator, which could still potentially be useful. So we add a new `--no-context-separator` flag that completely disables context separators even when the -A/-B/-C context flags are used. Closes #1390
2019-09-26 13:50:40 +02:00
Feature enhancements:
changelog: add notes about new file types
2020-02-15 17:13:08 +02:00
* Added or improved file type filtering for erb, diff, Gradle, HAML, Org,
ignore/types: add spec file type This is for RPM package SPEC files. Fixes #946, Closes #1449
2018-06-13 17:11:35 +02:00
Postscript, Skim, Slim, Slime, RPM Spec files, Typoscript, xml.
cli: add --include-zero flag This flag, when used in conjunction with --count or --count-matches, will print a result for each file searched even if there were zero matches in that file. This is off by default but can be enabled to make ripgrep behave more like grep. This also clarifies some of the defaults for the grep-printer::SummaryBuilder type. Closes #1370, Closes #1405
2019-10-17 04:03:00 +02:00
* [FEATURE #1370](https://github.com/BurntSushi/ripgrep/pull/1370):
Add `--include-zero` flag that shows files searched without matches.
cli: add --no-context-separator flag --context-separator='' still adds a new line separator, which could still potentially be useful. So we add a new `--no-context-separator` flag that completely disables context separators even when the -A/-B/-C context flags are used. Closes #1390
2019-09-26 13:50:40 +02:00
* [FEATURE #1390](https://github.com/BurntSushi/ripgrep/pull/1390):
cli: add --include-zero flag This flag, when used in conjunction with --count or --count-matches, will print a result for each file searched even if there were zero matches in that file. This is off by default but can be enabled to make ripgrep behave more like grep. This also clarifies some of the defaults for the grep-printer::SummaryBuilder type. Closes #1370, Closes #1405
2019-10-17 04:03:00 +02:00
Add `--no-context-separator` flag that always hides context separators.
cli: add --no-require-git flag This flag prevents ripgrep from requiring one to search a git repository in order to respect git-related ignore rules (global, .gitignore and local excludes). This actually corresponds to behavior ripgrep had long ago, but #934 changed that. It turns out that users were relying on this buggy behavior. In most cases, fixing it as simple as converting one's rules to .ignore or .rgignore files. Unfortunately, there are other use cases---like Perforce automatically respecting .gitignore files---that make a strong case for ripgrep to at least support this. The UX of a flag like this is absolutely atrocious. It's so obscure that it's really not worth explicitly calling it out anywhere. Moreover, the error cases that occur when this flag isn't used (but its behavior is desirable) will not be intuitive, do not seem easily detectable and will not guide users to this flag. Nevertheless, the motivation for this is just barely strong enough for me to begrudgingly accept this. Fixes #1414, Closes #1416
2020-02-17 21:43:22 +02:00
* [FEATURE #1414](https://github.com/BurntSushi/ripgrep/pull/1414):
Add `--no-require-git` flag to allow ripgrep to respect gitignores anywhere.
cli: add --no-ignore-exclude flag This commit adds a new --no-ignore-exclude flag that permits disabling the use of .git/info/exclude filtering. Local exclusions are manual configurations to a repository and are not shared, so it is sometimes useful to disable to get a consistent view of a repository. This also adds a new section to the man page that describes automatic filtering. Closes #1420
2019-11-07 02:23:57 +02:00
* [FEATURE #1420](https://github.com/BurntSushi/ripgrep/pull/1420):
Add `--no-ignore-exclude` to disregard rules in `.git/info/exclude` files.
cli: add --no-ignore-files flag The purpose of this flag is to force ripgrep to ignore all --ignore-file flags (whether they come before or after --no-ignore-files). This flag can be overridden with --ignore-files. Fixes #1466
2020-03-15 17:04:47 +02:00
* [FEATURE #1466](https://github.com/BurntSushi/ripgrep/pull/1466):
Add `--no-ignore-files` flag to disable all `--ignore-file` flags.
cli: add engine flag This permits switching between the different regex engine modes that ripgrep supports. The purpose of this flag is to make it easier to extend ripgrep with additional regex engines. Closes #1488, Closes #1502
2020-02-27 17:58:56 +02:00
* [FEATURE #1488](https://github.com/BurntSushi/ripgrep/pull/1488):
Add '--engine' flag for easier switching between regex engines.
changelog: add commit links ... now that we have stable identifiers.
2020-02-18 00:34:17 +02:00
* [FEATURE 75cbe88f](https://github.com/BurntSushi/ripgrep/commit/75cbe88f):
cli: add --no-unicode, deprecate --no-pcre2-unicode This adds a universal --no-unicode flag that is intended to work for all supported regex engines. There is no point in retaining --no-pcre2-unicode, so we make them aliases to the new flags and deprecate them.
2020-02-17 22:34:59 +02:00
Add `--no-unicode` flag. This works on all supported regex engines.
cli: add --no-context-separator flag --context-separator='' still adds a new line separator, which could still potentially be useful. So we add a new `--no-context-separator` flag that completely disables context separators even when the -A/-B/-C context flags are used. Closes #1390
2019-09-26 13:50:40 +02:00
changelog: update with bug fix
2019-08-02 13:37:27 +02:00
Bug fixes:
cli: make ripgrep work in non-existent directories It turns out that querying the CWD while in a directory that no longer exists results in an error. Since the CWD is queried every time ripgrep starts---whether it needs it or not---for dealing with glob matching, ripgrep winds up being completely useless inside a non-existent directory. We fix this in a few different ways: * Firstly, if std::env::current_dir() fails, then we fall back to trying to read the `PWD` environment variable. * If that fails, that we return a more sensible error message so that a user can at least react to the problem. Previously, the error message was inscrutable. * Finally, we try to avoid the problem altogether by building empty glob matchers if not globs were provided, thus side-stepping querying the CWD completely. Fixes #1291, Closes #1400
2020-02-17 04:03:07 +02:00
* [BUG #1291](https://github.com/BurntSushi/ripgrep/issues/1291):
ripgrep now works in non-existent directories.
grep-regex: fix inner literal extraction bug This appears to be another transcription bug from copying this code from the prefix literal detection from inside the regex crate. Namely, when it comes to inner literals, we only want to treat counted repetition as two separate cases: the case when the minimum match is 0 and the case when the minimum match is more than 0. In the former case, we treat `e{0,n}` as `e*` and in the latter we treat `e{m,n}` where `m >= 1` as just `e`. We could definitely do better here. e.g., This means regexes like `(foo){10}` will only have `foo` extracted as a literal, where searching for the full literal would likely be faster. The actual bug here was that we were not implementing this logic correctly. Namely, we weren't always "cutting" the literals in the second case to prevent them from being expanded. Fixes #1319, Closes #1367
2019-09-05 15:39:08 +02:00
* [BUG #1319](https://github.com/BurntSushi/ripgrep/issues/1319):
Fix match bug due to errant literal detection.
changelog: highlight a bad performance regression
2020-02-17 05:24:52 +02:00
* [**BUG #1335**](https://github.com/BurntSushi/ripgrep/issues/1335):
changelog: update with bug fix
2019-08-02 13:37:27 +02:00
Fixes a performance bug when searching plain text files with very long lines.
changelog: highlight a bad performance regression
2020-02-17 05:24:52 +02:00
This was a serious performance regression in some cases.
doc: document `all` file type This adds it to the guide and the docs for the --type flag. Fixes #1344, Closes #1472
2020-01-27 20:52:32 +02:00
* [BUG #1344](https://github.com/BurntSushi/ripgrep/issues/1344):
Document usage of `--type all`.
ignore: treat symbolic links to directories as directories Due to how walkdir works if symlinks are not followed, symlinks to directories are seen as simple files by ripgrep. This caused a panic in some cases due to receiving a WalkEvent::Exit event without a corresponding WalkEvent::Dir event. This is fixed by looking at the metadata of the file in the case of a symlink to determine if it's a directory. We are careful to only do this stat check when the depth of the entry is 0, as this bug only impacts us when 1) we aren't following symlinks generally and 2) the user provides a symlinked directory that we do follow as a top-level path to search. Fixes #1389, Closes #1397
2020-02-17 22:59:03 +02:00
* [BUG #1389](https://github.com/BurntSushi/ripgrep/issues/1389):
Fixes a bug where ripgrep would panic when searching a symlinked directory.
doc: note ripgrep's stdin behavior Fixes #1439
2020-03-15 15:55:31 +02:00
* [BUG #1439](https://github.com/BurntSushi/ripgrep/issues/1439):
Improve documentation for ripgrep's automatic stdin detection.
doc: remove CPU features from man pages It doesn't really belong in the man page since it's an artifact of a build/runtime configuration. Moreover, it inhibits reproducible builds. Fixes #1441
2020-03-15 16:06:23 +02:00
* [BUG #1441](https://github.com/BurntSushi/ripgrep/issues/1441):
Remove CPU features from man page.
doc: clarify globing behavior Fixes #1442, Fixes #1478
2020-03-15 16:28:59 +02:00
* [BUG #1442](https://github.com/BurntSushi/ripgrep/issues/1442),
[BUG #1478](https://github.com/BurntSushi/ripgrep/issues/1478):
Improve documentation of the `-g/--glob` flag.
ignore: use git commondir for sourcing .git/info/exclude Git looks for this file in GIT_COMMON_DIR, which is usually the same as GIT_DIR (.git). However, when searching inside a linked worktree, .git is usually a file that contains the path of the actual git dir, which in turn contains a file "commondir" which references the directory where info/exclude may reside, alongside other configuration shared across all worktrees. This directory is usually the git dir of the main worktree. Unlike git this does *not* read environment variables GIT_DIR and GIT_COMMON_DIR, because it is not clear how to interpret them when searching multiple repositories. Fixes #1445, Closes #1446
2019-12-11 18:41:04 +02:00
* [BUG #1445](https://github.com/BurntSushi/ripgrep/issues/1445):
ripgrep now respects ignore rules from .git/info/exclude in worktrees.
deb: fix fish completion install location It looks like `completions` is owned by Fish itself. Third party completions should go in `vendor_completions.d`. Fixes #1485
2020-02-17 20:33:35 +02:00
* [BUG #1485](https://github.com/BurntSushi/ripgrep/issues/1485):
Fish shell completions from the release Debian package are now installed to
`/usr/share/fish/vendor_completions.d/rg.fish`.
changelog: update with bug fix
2019-08-02 13:37:27 +02:00
changelog: start work on 11.0.2 release
2019-08-01 23:06:36 +02:00
11.0.2 (2019-08-01)
===================
ripgrep 11.0.2 is a new patch release that fixes a few bugs, including a
performance regression and a matching bug when using the `-F/--fixed-strings`
flag.
Feature enhancements:
* [FEATURE #1293](https://github.com/BurntSushi/ripgrep/issues/1293):
Added `--glob-case-insensitive` flag that makes `--glob` behave as `--iglob`.
cli: fix bug where last byte was stripped In an effort to strip line terminators, we assumed their existence. But a pattern file may not end with a line terminator, so we shouldn't unconditionally strip them. We fix this by moving to bstr's line handling, which does this for us automatically.
2019-04-19 13:10:24 +02:00
Bug fixes:
changelog: start work on 11.0.2 release
2019-08-01 23:06:36 +02:00
* [BUG #1246](https://github.com/BurntSushi/ripgrep/issues/1246):
Add translations to README, starting with an unofficial Chinese translation.
cli: fix bug where last byte was stripped In an effort to strip line terminators, we assumed their existence. But a pattern file may not end with a line terminator, so we shouldn't unconditionally strip them. We fix this by moving to bstr's line handling, which does this for us automatically.
2019-04-19 13:10:24 +02:00
* [BUG #1259](https://github.com/BurntSushi/ripgrep/issues/1259):
Fix bug where the last byte of a `-f file` was stripped if it wasn't a `\n`.
changelog: start work on 11.0.2 release
2019-08-01 23:06:36 +02:00
* [BUG #1261](https://github.com/BurntSushi/ripgrep/issues/1261):
Document that no error is reported when searching for `\n` with `-P/--pcre2`.
* [BUG #1284](https://github.com/BurntSushi/ripgrep/issues/1284):
Mention `.ignore` and `.rgignore` more prominently in the README.
* [BUG #1292](https://github.com/BurntSushi/ripgrep/issues/1292):
Fix bug where `--with-filename` was sometimes enabled incorrectly.
* [BUG #1268](https://github.com/BurntSushi/ripgrep/issues/1268):
Fix major performance regression in GitHub `x86_64-linux` binary release.
search: better errors for preprocessor commands If a preprocessor command could not be started, we now show some additional context with the error message. Previously, it showed something like this: some/file: No such file or directory (os error 2) Which is itself pretty misleading. Now it shows: some/file: preprocessor command could not start: '"nonexist" "some/file"': No such file or directory (os error 2) Fixes #1302
2019-06-17 01:00:09 +02:00
* [BUG #1302](https://github.com/BurntSushi/ripgrep/issues/1302):
Show better error messages when a non-existent preprocessor command is given.
changelog: start work on 11.0.2 release
2019-08-01 23:06:36 +02:00
* [BUG #1334](https://github.com/BurntSushi/ripgrep/issues/1334):
Fix match regression with `-F` flag when patterns contain meta characters.
cli: fix bug where last byte was stripped In an effort to strip line terminators, we assumed their existence. But a pattern file may not end with a line terminator, so we shouldn't unconditionally strip them. We fix this by moving to bstr's line handling, which does this for us automatically.
2019-04-19 13:10:24 +02:00
ripgrep: release 11.0.1
2019-04-16 19:10:29 +02:00
11.0.1 (2019-04-16)
===================
ripgrep 11.0.1 is a new patch release that fixes a search regression introduced
in the previous 11.0.0 release. In particular, ripgrep can enter an infinite
loop for some search patterns when searching invalid UTF-8.
Bug fixes:
* [BUG #1247](https://github.com/BurntSushi/ripgrep/issues/1247):
Fix search bug that can cause ripgrep to enter an infinite loop.
ripgrep: release 11.0.0
2019-04-16 00:09:17 +02:00
11.0.0 (2019-04-15)
===================
versioning: next version will be ripgrep 11 This sets up the release announcement and briefly describes the versioning change. The actual version change itself won't happen until the release. Closes #1172
2019-04-14 17:53:03 +02:00
ripgrep 11 is a new major version release of ripgrep that contains many bug
fixes, some performance improvements and a few feature enhancements. Notably,
ripgrep's user experience for binary file filtering has been improved. See the
[guide's new section on binary data](GUIDE.md#binary-data) for more details.
This release also marks a change in ripgrep's versioning. Where as the previous
version was `0.10.0`, this version is `11.0.0`. Moving forward, ripgrep's
major version will be increased a few times per year. ripgrep will continue to
be conservative with respect to backwards compatibility, but may occasionally
introduce breaking changes, which will always be documented in this CHANGELOG.
See [issue 1172](https://github.com/BurntSushi/ripgrep/issues/1172) for a bit
more detail on why this versioning change was made.
ripgrep: add --ignore-file-case-insensitive The --ignore-file-case-insensitive flag causes all .gitignore/.rgignore/.ignore files to have their globs matched without regard for case. Because this introduces a potentially significant performance regression, this is always disabled by default. Users that need case insensitive matching can enable it on a case by case basis. Closes #1164, Closes #1170
2019-01-21 03:32:34 +02:00
changelog: backfill it I went through every commit since the 0.10.0 release and added anything that I thought was missing.
2019-04-15 02:04:01 +02:00
This release increases the **minimum supported Rust version** from 1.28.0 to
1.34.0.
readme: encoding_rs's SIMD support is broken Add a note about it to the README. Also, remove mention of the avx-accel feature since it no longer exists. (bytecount now uses runtime detection to enable SIMD support.) Fixes #1175
2019-01-24 13:58:28 +02:00
**BREAKING CHANGES**:
exit: tweak exit status logic This changes how ripgrep emit exit status codes. In particular, any error that occurs while searching will now cause ripgrep to emit a `2` exit code, where as it previously would emit either a `0` or a `1` code based on whether it matched or not. That is, ripgrep would only emit a `2` exit code for a catastrophic error. This tweak includes additional logic that GNU grep adheres to, which seems like good sense. Namely, if -q/--quiet is given, and an error occurs and a match occurs, then ripgrep will emit a `0` exit code. Closes #1159
2019-01-26 22:42:55 +02:00
* ripgrep has tweaked its exit status codes to be more like GNU grep's. Namely,
if a non-fatal error occurs during a search, then ripgrep will now always
emit a `2` exit status code, regardless of whether a match is found or not.
Previously, ripgrep would only emit a `2` exit status code for a catastrophic
error (e.g., regex syntax error). One exception to this is if ripgrep is run
with `-q/--quiet`. In that case, if an error occurs and a match is found,
then ripgrep will exit with a `0` exit status code.
binary: rejigger ripgrep's handling of binary files This commit attempts to surface binary filtering in a slightly more user friendly way. Namely, before, ripgrep would silently stop searching a file if it detected a NUL byte, even if it had previously printed a match. This can lead to the user quite reasonably assuming that there are no more matches, since a partial search is fairly unintuitive. (ripgrep has this behavior by default because it really wants to NOT search binary files at all, just like it doesn't search gitignored or hidden files.) With this commit, if a match has already been printed and ripgrep detects a NUL byte, then it will print a warning message indicating that the search stopped prematurely. Moreover, this commit adds a new flag, --binary, which causes ripgrep to stop filtering binary files, but in a way that still avoids dumping binary data into terminals. That is, the --binary flag makes ripgrep behave more like grep's default behavior. For files explicitly specified in a search, e.g., `rg foo some-file`, then no binary filtering is applied (just like no gitignore and no hidden file filtering is applied). Instead, ripgrep behaves as if you gave the --binary flag for all explicitly given files. This was a fairly invasive change, and potentially increases the UX complexity of ripgrep around binary files. (Before, there were two binary modes, where as now there are three.) However, ripgrep is now a bit louder with warning messages when binary file detection might otherwise be hiding potential matches, so hopefully this is a net improvement. Finally, the `-uuu` convenience now maps to `--no-ignore --hidden --binary`, since this is closer to the actualy intent of the `--unrestricted` flag, i.e., to reduce ripgrep's smart filtering. As a consequence, `rg -uuu foo` should now search roughly the same number of bytes as `grep -r foo`, and `rg -uuua foo` should search roughly the same number of bytes as `grep -ra foo`. (The "roughly" weasel word is used because grep's and ripgrep's binary file detection might differ somewhat---perhaps based on buffer sizes---which can impact exactly what is and isn't searched.) See the numerous tests in tests/binary.rs for intended behavior. Fixes #306, Fixes #855
2019-04-09 01:28:38 +02:00
* Supplying the `-u/--unrestricted` flag three times is now equivalent to
supplying `--no-ignore --hidden --binary`. Previously, `-uuu` was equivalent
to `--no-ignore --hidden --text`. The difference is that `--binary` disables
binary file filtering without potentially dumping binary data into your
terminal. That is, `rg -uuu foo` should now be equivalent to `grep -r foo`.
readme: encoding_rs's SIMD support is broken Add a note about it to the README. Also, remove mention of the avx-accel feature since it no longer exists. (bytecount now uses runtime detection to enable SIMD support.) Fixes #1175
2019-01-24 13:58:28 +02:00
* The `avx-accel` feature of ripgrep has been removed since it is no longer
necessary. All uses of AVX in ripgrep are now enabled automatically via
ripgrep: release 11.0.0
2019-04-16 00:09:17 +02:00
runtime CPU feature detection. The `simd-accel` feature does remain available
(only for enabling SIMD for transcoding), however, it does increase
compilation times substantially at the moment.
readme: encoding_rs's SIMD support is broken Add a note about it to the README. Also, remove mention of the avx-accel feature since it no longer exists. (bytecount now uses runtime detection to enable SIMD support.) Fixes #1175
2019-01-24 13:58:28 +02:00
regex: make multi-literal searcher faster This makes the case of searching for a dictionary of a very large number of literals much much faster. (~10x or so.) In particular, we achieve this by short-circuiting the construction of a full regex when we know we have a simple alternation of literals. Building the regex for a large dictionary (>100,000 literals) turns out to be quite slow, even if it internally will dispatch to Aho-Corasick. Even that isn't quite enough. It turns out that even *parsing* such a regex is quite slow. So when the -F/--fixed-strings flag is set, we short circuit regex parsing completely and jump straight to Aho-Corasick. We aren't quite as fast as GNU grep here, but it's much closer (less than 2x slower). In general, this is somewhat of a hack. In particular, it seems plausible that this optimization could be implemented entirely in the regex engine. Unfortunately, the regex engine's internals are just not amenable to this at all, so it would require a larger refactoring effort. For now, it's good enough to add this fairly simple hack at a higher level. Unfortunately, if you don't pass -F/--fixed-strings, then ripgrep will be slower, because of the aforementioned missing optimization. Moreover, passing flags like `-i` or `-S` will cause ripgrep to abandon this optimization and fall back to something potentially much slower. Again, this fix really needs to happen inside the regex engine, although we might be able to special case -i when the input literals are pure ASCII via Aho-Corasick's `ascii_case_insensitive`. Fixes #497, Fixes #838
2019-04-08 00:43:01 +02:00
Performance improvements:
* [PERF #497](https://github.com/BurntSushi/ripgrep/issues/497),
[PERF #838](https://github.com/BurntSushi/ripgrep/issues/838):
Make `rg -F -f dictionary-of-literals` much faster.
ripgrep: add --ignore-file-case-insensitive The --ignore-file-case-insensitive flag causes all .gitignore/.rgignore/.ignore files to have their globs matched without regard for case. Because this introduces a potentially significant performance regression, this is always disabled by default. Users that need case insensitive matching can enable it on a case by case basis. Closes #1164, Closes #1170
2019-01-21 03:32:34 +02:00
Feature enhancements:
changelog: backfill it I went through every commit since the 0.10.0 release and added anything that I thought was missing.
2019-04-15 02:04:01 +02:00
* Added or improved file type filtering for Apache Thrift, ASP, Bazel, Brotli,
BuildStream, bzip2, C, C++, Cython, gzip, Java, Make, Postscript, QML, Tex,
changelog: small fixups
2019-04-15 02:21:55 +02:00
XML, xz, zig and zstd.
binary: rejigger ripgrep's handling of binary files This commit attempts to surface binary filtering in a slightly more user friendly way. Namely, before, ripgrep would silently stop searching a file if it detected a NUL byte, even if it had previously printed a match. This can lead to the user quite reasonably assuming that there are no more matches, since a partial search is fairly unintuitive. (ripgrep has this behavior by default because it really wants to NOT search binary files at all, just like it doesn't search gitignored or hidden files.) With this commit, if a match has already been printed and ripgrep detects a NUL byte, then it will print a warning message indicating that the search stopped prematurely. Moreover, this commit adds a new flag, --binary, which causes ripgrep to stop filtering binary files, but in a way that still avoids dumping binary data into terminals. That is, the --binary flag makes ripgrep behave more like grep's default behavior. For files explicitly specified in a search, e.g., `rg foo some-file`, then no binary filtering is applied (just like no gitignore and no hidden file filtering is applied). Instead, ripgrep behaves as if you gave the --binary flag for all explicitly given files. This was a fairly invasive change, and potentially increases the UX complexity of ripgrep around binary files. (Before, there were two binary modes, where as now there are three.) However, ripgrep is now a bit louder with warning messages when binary file detection might otherwise be hiding potential matches, so hopefully this is a net improvement. Finally, the `-uuu` convenience now maps to `--no-ignore --hidden --binary`, since this is closer to the actualy intent of the `--unrestricted` flag, i.e., to reduce ripgrep's smart filtering. As a consequence, `rg -uuu foo` should now search roughly the same number of bytes as `grep -r foo`, and `rg -uuua foo` should search roughly the same number of bytes as `grep -ra foo`. (The "roughly" weasel word is used because grep's and ripgrep's binary file detection might differ somewhat---perhaps based on buffer sizes---which can impact exactly what is and isn't searched.) See the numerous tests in tests/binary.rs for intended behavior. Fixes #306, Fixes #855
2019-04-09 01:28:38 +02:00
* [FEATURE #855](https://github.com/BurntSushi/ripgrep/issues/855):
Add `--binary` flag for disabling binary file filtering.
printer: support previews for long lines This commit adds support for showing a preview of long lines. While the default still remains as completely suppressing the entire line, this new functionality will show the first N graphemes of a matching line, including the number of matches that are suppressed. This was unfortunately a fairly invasive change to the printer that required a bit of refactoring. On the bright side, the single line and multi-line coloring are now more unified than they were before. Closes #1078
2019-04-14 00:35:24 +02:00
* [FEATURE #1078](https://github.com/BurntSushi/ripgrep/pull/1078):
ripgrep: max-column-preview --> max-columns-preview Credit to @okdana for catching this. This naming is a bit more consistent with the existing --max-columns flag.
2019-04-15 12:51:51 +02:00
Add `--max-columns-preview` flag for showing a preview of long lines.
changelog: brotli/zstd addition
2019-01-23 03:57:28 +02:00
* [FEATURE #1099](https://github.com/BurntSushi/ripgrep/pull/1099):
Add support for Brotli and Zstd to the `-z/--search-zip` flag.
config: add --no-ignore-dot flag This flag causes ripgrep to ignore `.ignore` files. Closes #1138
2019-01-26 20:40:12 +02:00
* [FEATURE #1138](https://github.com/BurntSushi/ripgrep/pull/1138):
Add `--no-ignore-dot` flag for ignoring `.ignore` files.
ripgrep: add --auto-hybrid-regex flag This flag, when set, will automatically dispatch to PCRE2 if the given regex cannot be compiled by Rust's regex engine. If both engines fail to compile the regex, then both errors are surfaced. Closes #1155
2019-04-14 23:39:37 +02:00
* [FEATURE #1155](https://github.com/BurntSushi/ripgrep/pull/1155):
Add `--auto-hybrid-regex` flag for automatically falling back to PCRE2.
exit: tweak exit status logic This changes how ripgrep emit exit status codes. In particular, any error that occurs while searching will now cause ripgrep to emit a `2` exit code, where as it previously would emit either a `0` or a `1` code based on whether it matched or not. That is, ripgrep would only emit a `2` exit code for a catastrophic error. This tweak includes additional logic that GNU grep adheres to, which seems like good sense. Namely, if -q/--quiet is given, and an error occurs and a match occurs, then ripgrep will emit a `0` exit code. Closes #1159
2019-01-26 22:42:55 +02:00
* [FEATURE #1159](https://github.com/BurntSushi/ripgrep/pull/1159):
ripgrep's exit status logic should now match GNU grep. See updated man page.
changelog: backfill it I went through every commit since the 0.10.0 release and added anything that I thought was missing.
2019-04-15 02:04:01 +02:00
* [FEATURE #1164](https://github.com/BurntSushi/ripgrep/pull/1164):
changelog: small fixups
2019-04-15 02:21:55 +02:00
Add `--ignore-file-case-insensitive` for case insensitive ignore globs.
changelog: backfill it I went through every commit since the 0.10.0 release and added anything that I thought was missing.
2019-04-15 02:04:01 +02:00
* [FEATURE #1185](https://github.com/BurntSushi/ripgrep/pull/1185):
Add `-I` flag as a short option for the `--no-filename` flag.
* [FEATURE #1207](https://github.com/BurntSushi/ripgrep/pull/1207):
Add `none` value to `-E/--encoding` to forcefully disable all transcoding.
changelog: small fixups
2019-04-15 02:21:55 +02:00
* [FEATURE da9d7204](https://github.com/BurntSushi/ripgrep/commit/da9d7204):
ripgrep: add --pcre2-version flag This flag will output details about the version of PCRE2 that ripgrep is using (if any).
2019-04-14 22:46:02 +02:00
Add `--pcre2-version` for querying showing PCRE2 version information.
ripgrep: add --ignore-file-case-insensitive The --ignore-file-case-insensitive flag causes all .gitignore/.rgignore/.ignore files to have their globs matched without regard for case. Because this introduces a potentially significant performance regression, this is always disabled by default. Users that need case insensitive matching can enable it on a case by case basis. Closes #1164, Closes #1170
2019-01-21 03:32:34 +02:00
printer: fix path handling in summarizer This commit fixes a bug where both of the following commands always reported an error: rg --files-with-matches foo file rg --files-without-match foo file In particular, the printer was erroneously respecting the `path` option even the the summary kind was `PathWithMatch` or `PathWithoutMatch`. The documented behavior is that those summary kinds always require a path, and thus, the `path` option has no effect. We fix this by correcting the case analysis. This also fixes a bug where the exit code for `--files-without-match` was not set correctly. We update the printer's `has_match` method to report the correct value. Fixes #1106, Closes #1130
2018-12-01 14:31:33 +02:00
Bug fixes:
binary: rejigger ripgrep's handling of binary files This commit attempts to surface binary filtering in a slightly more user friendly way. Namely, before, ripgrep would silently stop searching a file if it detected a NUL byte, even if it had previously printed a match. This can lead to the user quite reasonably assuming that there are no more matches, since a partial search is fairly unintuitive. (ripgrep has this behavior by default because it really wants to NOT search binary files at all, just like it doesn't search gitignored or hidden files.) With this commit, if a match has already been printed and ripgrep detects a NUL byte, then it will print a warning message indicating that the search stopped prematurely. Moreover, this commit adds a new flag, --binary, which causes ripgrep to stop filtering binary files, but in a way that still avoids dumping binary data into terminals. That is, the --binary flag makes ripgrep behave more like grep's default behavior. For files explicitly specified in a search, e.g., `rg foo some-file`, then no binary filtering is applied (just like no gitignore and no hidden file filtering is applied). Instead, ripgrep behaves as if you gave the --binary flag for all explicitly given files. This was a fairly invasive change, and potentially increases the UX complexity of ripgrep around binary files. (Before, there were two binary modes, where as now there are three.) However, ripgrep is now a bit louder with warning messages when binary file detection might otherwise be hiding potential matches, so hopefully this is a net improvement. Finally, the `-uuu` convenience now maps to `--no-ignore --hidden --binary`, since this is closer to the actualy intent of the `--unrestricted` flag, i.e., to reduce ripgrep's smart filtering. As a consequence, `rg -uuu foo` should now search roughly the same number of bytes as `grep -r foo`, and `rg -uuua foo` should search roughly the same number of bytes as `grep -ra foo`. (The "roughly" weasel word is used because grep's and ripgrep's binary file detection might differ somewhat---perhaps based on buffer sizes---which can impact exactly what is and isn't searched.) See the numerous tests in tests/binary.rs for intended behavior. Fixes #306, Fixes #855
2019-04-09 01:28:38 +02:00
* [BUG #306](https://github.com/BurntSushi/ripgrep/issues/306),
[BUG #855](https://github.com/BurntSushi/ripgrep/issues/855):
Improve the user experience for ripgrep's binary file filtering.
globset: permit ** to appear anywhere Previously, `man gitignore` specified that `**` was invalid unless it was used in one of a few specific circumstances, i.e., `**`, `a/**`, `**/b` or `a/**/b`. That is, `**` always had to be surrounded by either a path separator or the beginning/end of the pattern. It turns out that git itself has treated `**` outside the above contexts as valid for quite a while, so there was an inconsistency between the spec `man gitignore` and the implementation, and it wasn't clear which was actually correct. @okdana filed a bug against git[1] and got this fixed. The spec was wrong, which has now been fixed [2] and updated[2]. This commit brings ripgrep in line with git and treats `**` outside of the above contexts as two consecutive `*` patterns. We deprecate the `InvalidRecursive` error since it is no longer used. Fixes #373, Fixes #1098 [1] - https://public-inbox.org/git/C16A9F17-0375-42F9-90A9-A92C9F3D8BBA@dana.is [2] - https://github.com/git/git/commit/627186d0206dcb219c43f8e6670b4487802a4921 [3] - https://git-scm.com/docs/gitignore
2019-01-24 02:46:15 +02:00
* [BUG #373](https://github.com/BurntSushi/ripgrep/issues/373),
[BUG #1098](https://github.com/BurntSushi/ripgrep/issues/1098):
`**` is now accepted as valid syntax anywhere in a glob.
changelog: BUG #916 This was fixed by bumping the MSRV above Rust 1.28. Fixes #916
2019-01-27 20:15:17 +02:00
* [BUG #916](https://github.com/BurntSushi/ripgrep/issues/916):
ripgrep no longer hangs when searching `/proc` with a zombie process present.
changelog: backfill it I went through every commit since the 0.10.0 release and added anything that I thought was missing.
2019-04-15 02:04:01 +02:00
* [BUG #1052](https://github.com/BurntSushi/ripgrep/issues/1052):
Fix bug where ripgrep could panic when transcoding UTF-16 files.
* [BUG #1055](https://github.com/BurntSushi/ripgrep/issues/1055):
Suggest `-U/--multiline` when a pattern contains a `\n`.
* [BUG #1063](https://github.com/BurntSushi/ripgrep/issues/1063):
Always strip a BOM if it's present, even for UTF-8.
* [BUG #1064](https://github.com/BurntSushi/ripgrep/issues/1064):
Fix inner literal detection that could lead to incorrect matches.
* [BUG #1079](https://github.com/BurntSushi/ripgrep/issues/1079):
Fixes a bug where the order of globs could result in missing a match.
* [BUG #1089](https://github.com/BurntSushi/ripgrep/issues/1089):
Fix another bug where ripgrep could panic when transcoding UTF-16 files.
doc: add note about inverted flags Fixes #1091
2019-01-26 21:12:47 +02:00
* [BUG #1091](https://github.com/BurntSushi/ripgrep/issues/1091):
Add note about inverted flags to the man page.
doc: note cases of exorbitant memory usage Fixes #1189
2019-04-14 16:53:39 +02:00
* [BUG #1093](https://github.com/BurntSushi/ripgrep/pull/1093):
Fix handling of literal slashes in gitignore patterns.
changelog: BUG #1095
2019-01-26 20:40:59 +02:00
* [BUG #1095](https://github.com/BurntSushi/ripgrep/issues/1095):
Fix corner cases involving the `--crlf` flag.
changelog: backfill it I went through every commit since the 0.10.0 release and added anything that I thought was missing.
2019-04-15 02:04:01 +02:00
* [BUG #1101](https://github.com/BurntSushi/ripgrep/issues/1101):
Fix AsciiDoc escaping for man page output.
doc: clarify automatic encoding detection Fixes #1103
2019-01-26 20:55:17 +02:00
* [BUG #1103](https://github.com/BurntSushi/ripgrep/issues/1103):
Clarify what `--encoding auto` does.
printer: fix path handling in summarizer This commit fixes a bug where both of the following commands always reported an error: rg --files-with-matches foo file rg --files-without-match foo file In particular, the printer was erroneously respecting the `path` option even the the summary kind was `PathWithMatch` or `PathWithoutMatch`. The documented behavior is that those summary kinds always require a path, and thus, the `path` option has no effect. We fix this by correcting the case analysis. This also fixes a bug where the exit code for `--files-without-match` was not set correctly. We update the printer's `has_match` method to report the correct value. Fixes #1106, Closes #1130
2018-12-01 14:31:33 +02:00
* [BUG #1106](https://github.com/BurntSushi/ripgrep/issues/1106):
`--files-with-matches` and `--files-without-match` work with one file.
changelog: BUG #1121
2019-01-24 03:06:01 +02:00
* [BUG #1121](https://github.com/BurntSushi/ripgrep/issues/1121):
changelog: backfill it I went through every commit since the 0.10.0 release and added anything that I thought was missing.
2019-04-15 02:04:01 +02:00
Fix bug that was triggering Windows antimalware when using the `--files`
flag.
args: prevent panicking in 'rg -h | rg' Previously, we relied on clap to handle printing either an error message, or --help/--version output, in addition to setting the exit status code. Unfortunately, for --help/--version output, clap was panicking if the write failed, which can happen in fairly common scenarios via a broken pipe error. e.g., `rg -h | head`. We fix this by using clap's "safe" API and doing the printing ourselves. We also set the exit code to `2` when an invalid command has been given. Fixes #1125 and partially addresses #1159
2019-01-26 21:36:34 +02:00
* [BUG #1125](https://github.com/BurntSushi/ripgrep/issues/1125),
[BUG #1159](https://github.com/BurntSushi/ripgrep/issues/1159):
ripgrep shouldn't panic for `rg -h | rg` and should emit correct exit status.
changelog: small fixups
2019-04-15 02:21:55 +02:00
* [BUG #1144](https://github.com/BurntSushi/ripgrep/issues/1144):
changelog: backfill it I went through every commit since the 0.10.0 release and added anything that I thought was missing.
2019-04-15 02:04:01 +02:00
Fixes a bug where line numbers could be wrong on big-endian machines.
changelog: BUG #1154
2019-01-27 20:05:50 +02:00
* [BUG #1154](https://github.com/BurntSushi/ripgrep/issues/1154):
Windows files with "hidden" attribute are now treated as hidden.
changelog: BUG #1174
2019-01-24 02:19:26 +02:00
* [BUG #1173](https://github.com/BurntSushi/ripgrep/issues/1173):
Fix handling of `**` patterns in gitignore files.
* [BUG #1174](https://github.com/BurntSushi/ripgrep/issues/1174):
Fix handling of repeated `**` patterns in gitignore files.
search: fix -F and -f interaction bug This fixes what appears to be a pretty egregious regression where the `-F/--fixed-strings` flag wasn't be applied to patterns supplied via the `-f/--file` flag. The same bug existed for the `-x/--line-regexp` flag as well, which we fix here. Fixes #1176
2019-01-26 23:00:43 +02:00
* [BUG #1176](https://github.com/BurntSushi/ripgrep/issues/1176):
Fix bug where `-F`/`-x` weren't applied to patterns given via `-f`.
doc: note cases of exorbitant memory usage Fixes #1189
2019-04-14 16:53:39 +02:00
* [BUG #1189](https://github.com/BurntSushi/ripgrep/issues/1189):
Document cases where ripgrep may use a lot of memory.
changelog: backfill it I went through every commit since the 0.10.0 release and added anything that I thought was missing.
2019-04-15 02:04:01 +02:00
* [BUG #1203](https://github.com/BurntSushi/ripgrep/issues/1203):
Fix a matching bug related to the suffix literal optimization.
changelog: small fixups
2019-04-15 02:21:55 +02:00
* [BUG 8f14cb18](https://github.com/BurntSushi/ripgrep/commit/8f14cb18):
Increase the default stack size for PCRE2's JIT.
printer: fix path handling in summarizer This commit fixes a bug where both of the following commands always reported an error: rg --files-with-matches foo file rg --files-without-match foo file In particular, the printer was erroneously respecting the `path` option even the the summary kind was `PathWithMatch` or `PathWithoutMatch`. The documented behavior is that those summary kinds always require a path, and thus, the `path` option has no effect. We fix this by correcting the case analysis. This also fixes a bug where the exit code for `--files-without-match` was not set correctly. We update the printer's `has_match` method to report the correct value. Fixes #1106, Closes #1130
2018-12-01 14:31:33 +02:00
ripgrep: add --ignore-file-case-insensitive The --ignore-file-case-insensitive flag causes all .gitignore/.rgignore/.ignore files to have their globs matched without regard for case. Because this introduces a potentially significant performance regression, this is always disabled by default. Users that need case insensitive matching can enable it on a case by case basis. Closes #1164, Closes #1170
2019-01-21 03:32:34 +02:00
changelog: add release date
2018-09-07 19:56:59 +02:00
0.10.0 (2018-09-07)
===================
changelog: massive update for libripgrep This commit updates the CHANGELOG to reflect all the work done to make libripgrep a reality. * Closes #162 (libripgrep) * Closes #176 (multiline search) * Closes #188 (opt-in PCRE2 support) * Closes #244 (JSON output) * Closes #416 (Windows CRLF support) * Closes #917 (trim prefix whitespace) * Closes #993 (add --null-data flag) * Closes #997 (--passthru works with --replace) * Fixes #2 (memory maps and context handling work) * Fixes #200 (ripgrep stops when pipe is closed) * Fixes #389 (more intuitive `-w/--word-regexp`) * Fixes #643 (detection of stdin on Windows is better) * Fixes #441, Fixes #690, Fixes #980 (empty matching lines are weird) * Fixes #764 (coalesce color escapes) * Fixes #922 (memory maps failing is no big deal) * Fixes #937 (color escapes no longer used for empty matches) * Fixes #940 (--passthru does not impact exit status) * Fixes #1013 (show runtime CPU features in --version output)
2018-08-19 16:16:19 +02:00
This is a new minor version release of ripgrep that contains some major new
features, a huge number of bug fixes, and is the first release based on
libripgrep. The entirety of ripgrep's core search and printing code has been
rewritten and generalized so that anyone can make use of it.
Major new features include PCRE2 support, multi-line search and a JSON output
format.
**BREAKING CHANGES**:
ripgrep: move minimum version to Rust stable This also updates some code to make use of our more liberal versioning requirement, including the use of crossbeam-channel instead of the MsQueue from the older an unmaintained crossbeam 0.3. This does regrettably add a sizable number of dependencies, however, compile times seem mostly unaffected. Closes #1019
2018-08-22 01:47:12 +02:00
* The minimum version required to compile Rust has now changed to track the
latest stable version of Rust. Patch releases will continue to compile with
the same version of Rust as the previous patch release, but new minor
versions will use the current stable version of the Rust compile as its
minimum supported version.
changelog: massive update for libripgrep This commit updates the CHANGELOG to reflect all the work done to make libripgrep a reality. * Closes #162 (libripgrep) * Closes #176 (multiline search) * Closes #188 (opt-in PCRE2 support) * Closes #244 (JSON output) * Closes #416 (Windows CRLF support) * Closes #917 (trim prefix whitespace) * Closes #993 (add --null-data flag) * Closes #997 (--passthru works with --replace) * Fixes #2 (memory maps and context handling work) * Fixes #200 (ripgrep stops when pipe is closed) * Fixes #389 (more intuitive `-w/--word-regexp`) * Fixes #643 (detection of stdin on Windows is better) * Fixes #441, Fixes #690, Fixes #980 (empty matching lines are weird) * Fixes #764 (coalesce color escapes) * Fixes #922 (memory maps failing is no big deal) * Fixes #937 (color escapes no longer used for empty matches) * Fixes #940 (--passthru does not impact exit status) * Fixes #1013 (show runtime CPU features in --version output)
2018-08-19 16:16:19 +02:00
* The match semantics of `-w/--word-regexp` have changed slightly. They used
to be `\b(?:<your pattern>)\b`, but now it's
changelog: update This brings the changelog up to date with HEAD and rewords a few things.
2018-08-30 00:25:08 +02:00
`(?:^|\W)(?:<your pattern>)(?:$|\W)`. This matches the behavior of GNU grep
changelog: fix typo
2018-08-30 00:46:34 +02:00
and is believed to be closer to the intended semantics of the flag. See
[#389](https://github.com/BurntSushi/ripgrep/issues/389) for more details.
changelog: massive update for libripgrep This commit updates the CHANGELOG to reflect all the work done to make libripgrep a reality. * Closes #162 (libripgrep) * Closes #176 (multiline search) * Closes #188 (opt-in PCRE2 support) * Closes #244 (JSON output) * Closes #416 (Windows CRLF support) * Closes #917 (trim prefix whitespace) * Closes #993 (add --null-data flag) * Closes #997 (--passthru works with --replace) * Fixes #2 (memory maps and context handling work) * Fixes #200 (ripgrep stops when pipe is closed) * Fixes #389 (more intuitive `-w/--word-regexp`) * Fixes #643 (detection of stdin on Windows is better) * Fixes #441, Fixes #690, Fixes #980 (empty matching lines are weird) * Fixes #764 (coalesce color escapes) * Fixes #922 (memory maps failing is no big deal) * Fixes #937 (color escapes no longer used for empty matches) * Fixes #940 (--passthru does not impact exit status) * Fixes #1013 (show runtime CPU features in --version output)
2018-08-19 16:16:19 +02:00
Feature enhancements:
* [FEATURE #162](https://github.com/BurntSushi/ripgrep/issues/162):
changelog: update This brings the changelog up to date with HEAD and rewords a few things.
2018-08-30 00:25:08 +02:00
libripgrep is now a thing. The primary crate is
[`grep`](https://docs.rs/grep).
changelog: massive update for libripgrep This commit updates the CHANGELOG to reflect all the work done to make libripgrep a reality. * Closes #162 (libripgrep) * Closes #176 (multiline search) * Closes #188 (opt-in PCRE2 support) * Closes #244 (JSON output) * Closes #416 (Windows CRLF support) * Closes #917 (trim prefix whitespace) * Closes #993 (add --null-data flag) * Closes #997 (--passthru works with --replace) * Fixes #2 (memory maps and context handling work) * Fixes #200 (ripgrep stops when pipe is closed) * Fixes #389 (more intuitive `-w/--word-regexp`) * Fixes #643 (detection of stdin on Windows is better) * Fixes #441, Fixes #690, Fixes #980 (empty matching lines are weird) * Fixes #764 (coalesce color escapes) * Fixes #922 (memory maps failing is no big deal) * Fixes #937 (color escapes no longer used for empty matches) * Fixes #940 (--passthru does not impact exit status) * Fixes #1013 (show runtime CPU features in --version output)
2018-08-19 16:16:19 +02:00
* [FEATURE #176](https://github.com/BurntSushi/ripgrep/issues/176):
Add `-U/--multiline` flag that permits matching over multiple lines.
* [FEATURE #188](https://github.com/BurntSushi/ripgrep/issues/188):
Add `-P/--pcre2` flag that gives support for look-around and backreferences.
* [FEATURE #244](https://github.com/BurntSushi/ripgrep/issues/244):
Add `--json` flag that prints results in a JSON Lines format.
changelog: update This brings the changelog up to date with HEAD and rewords a few things.
2018-08-30 00:25:08 +02:00
* [FEATURE #321](https://github.com/BurntSushi/ripgrep/issues/321):
Add `--one-file-system` flag to skip directories on different file systems.
* [FEATURE #404](https://github.com/BurntSushi/ripgrep/issues/404):
Add `--sort` and `--sortr` flag for more sorting. Deprecate `--sort-files`.
changelog: massive update for libripgrep This commit updates the CHANGELOG to reflect all the work done to make libripgrep a reality. * Closes #162 (libripgrep) * Closes #176 (multiline search) * Closes #188 (opt-in PCRE2 support) * Closes #244 (JSON output) * Closes #416 (Windows CRLF support) * Closes #917 (trim prefix whitespace) * Closes #993 (add --null-data flag) * Closes #997 (--passthru works with --replace) * Fixes #2 (memory maps and context handling work) * Fixes #200 (ripgrep stops when pipe is closed) * Fixes #389 (more intuitive `-w/--word-regexp`) * Fixes #643 (detection of stdin on Windows is better) * Fixes #441, Fixes #690, Fixes #980 (empty matching lines are weird) * Fixes #764 (coalesce color escapes) * Fixes #922 (memory maps failing is no big deal) * Fixes #937 (color escapes no longer used for empty matches) * Fixes #940 (--passthru does not impact exit status) * Fixes #1013 (show runtime CPU features in --version output)
2018-08-19 16:16:19 +02:00
* [FEATURE #416](https://github.com/BurntSushi/ripgrep/issues/416):
Add `--crlf` flag to permit `$` to work with carriage returns on Windows.
* [FEATURE #917](https://github.com/BurntSushi/ripgrep/issues/917):
The `--trim` flag strips prefix whitespace from all lines printed.
* [FEATURE #993](https://github.com/BurntSushi/ripgrep/issues/993):
Add `--null-data` flag, which makes ripgrep use NUL as a line terminator.
* [FEATURE #997](https://github.com/BurntSushi/ripgrep/issues/997):
The `--passthru` flag now works with the `--replace` flag.
changelog: assign feature id
2018-09-05 05:24:22 +02:00
* [FEATURE #1038-1](https://github.com/BurntSushi/ripgrep/issues/1038):
ripgrep: add --line-buffered and --block-buffered These flags provide granular control over ripgrep's buffering strategy. The --line-buffered flag can be genuinely useful in certain types of shell pipelines. The --block-buffered flag has a murkier use case, but we add it for completeness.
2018-09-05 03:39:05 +02:00
Add `--line-buffered` and `--block-buffered` for forcing a buffer strategy.
changelog: assign feature id
2018-09-05 05:24:22 +02:00
* [FEATURE #1038-2](https://github.com/BurntSushi/ripgrep/issues/1038):
ripgrep: add --pre-glob flag The --pre-glob flag is like the --glob flag, except it applies to filtering files through the preprocessor instead of for search. This makes it possible to apply the preprocessor to only a small subset of files, which can greatly reduce the process overhead of using a preprocessor when searching large directories.
2018-09-05 04:45:24 +02:00
Add `--pre-glob` for filtering files through the `--pre` flag.
changelog: massive update for libripgrep This commit updates the CHANGELOG to reflect all the work done to make libripgrep a reality. * Closes #162 (libripgrep) * Closes #176 (multiline search) * Closes #188 (opt-in PCRE2 support) * Closes #244 (JSON output) * Closes #416 (Windows CRLF support) * Closes #917 (trim prefix whitespace) * Closes #993 (add --null-data flag) * Closes #997 (--passthru works with --replace) * Fixes #2 (memory maps and context handling work) * Fixes #200 (ripgrep stops when pipe is closed) * Fixes #389 (more intuitive `-w/--word-regexp`) * Fixes #643 (detection of stdin on Windows is better) * Fixes #441, Fixes #690, Fixes #980 (empty matching lines are weird) * Fixes #764 (coalesce color escapes) * Fixes #922 (memory maps failing is no big deal) * Fixes #937 (color escapes no longer used for empty matches) * Fixes #940 (--passthru does not impact exit status) * Fixes #1013 (show runtime CPU features in --version output)
2018-08-19 16:16:19 +02:00
Bug fixes:
* [BUG #2](https://github.com/BurntSushi/ripgrep/issues/2):
Searching with non-zero context can now use memory maps if appropriate.
* [BUG #200](https://github.com/BurntSushi/ripgrep/issues/200):
ripgrep will now stop correctly when its output pipe is closed.
* [BUG #389](https://github.com/BurntSushi/ripgrep/issues/389):
The `-w/--word-regexp` flag now works more intuitively.
* [BUG #643](https://github.com/BurntSushi/ripgrep/issues/643):
Detection of readable stdin has improved on Windows.
* [BUG #441](https://github.com/BurntSushi/ripgrep/issues/441),
[BUG #690](https://github.com/BurntSushi/ripgrep/issues/690),
[BUG #980](https://github.com/BurntSushi/ripgrep/issues/980):
Matching empty lines now works correctly in several corner cases.
* [BUG #764](https://github.com/BurntSushi/ripgrep/issues/764):
Color escape sequences now coalesce, which reduces output size.
release: better support for binary Debian package This commit beefs up the package metadata used by the 'cargo deb' tool to produce a binary dpkg. In particular, we now include ripgrep's man page. This commit includes a new script, 'ci/build_deb.sh', which will handle the build process for a dpkg, which has become a bit more nuanced than just running 'cargo deb'. We don't (yet) run this script in CI. Fixes #842
2018-08-22 03:26:18 +02:00
* [BUG #842](https://github.com/BurntSushi/ripgrep/issues/842):
Add man page to binary Debian package.
changelog: massive update for libripgrep This commit updates the CHANGELOG to reflect all the work done to make libripgrep a reality. * Closes #162 (libripgrep) * Closes #176 (multiline search) * Closes #188 (opt-in PCRE2 support) * Closes #244 (JSON output) * Closes #416 (Windows CRLF support) * Closes #917 (trim prefix whitespace) * Closes #993 (add --null-data flag) * Closes #997 (--passthru works with --replace) * Fixes #2 (memory maps and context handling work) * Fixes #200 (ripgrep stops when pipe is closed) * Fixes #389 (more intuitive `-w/--word-regexp`) * Fixes #643 (detection of stdin on Windows is better) * Fixes #441, Fixes #690, Fixes #980 (empty matching lines are weird) * Fixes #764 (coalesce color escapes) * Fixes #922 (memory maps failing is no big deal) * Fixes #937 (color escapes no longer used for empty matches) * Fixes #940 (--passthru does not impact exit status) * Fixes #1013 (show runtime CPU features in --version output)
2018-08-19 16:16:19 +02:00
* [BUG #922](https://github.com/BurntSushi/ripgrep/issues/922):
ripgrep is now more robust with respect to memory maps failing.
* [BUG #937](https://github.com/BurntSushi/ripgrep/issues/937):
Color escape sequences are no longer emitted for empty matches.
* [BUG #940](https://github.com/BurntSushi/ripgrep/issues/940):
Context from the `--passthru` flag should not impact process exit status.
ignore: fix false positive in path_is_symlink This commit fixes a bug where the first path always reported itself as as symlink via `path_is_symlink`. Part of this fix includes updating walkdir to 2.2.1, which also includes a corresponding bug fix. Fixes #984
2018-08-22 03:58:27 +02:00
* [BUG #984](https://github.com/BurntSushi/ripgrep/issues/984):
Fixes bug in `ignore` crate where first path was always treated as a symlink.
grep-cli: introduce new grep-cli crate This commit moves a lot of "utility" code from ripgrep core into grep-cli. Any one of these things might not be worth creating a new crate, but combining everything together results in a fair number of a convenience routines that make up a decent sized crate. There is potentially more we could move into the crate, but much of what remains in ripgrep core is almost entirely dealing with the number of flags we support. In the course of doing moving things to the grep-cli crate, we clean up a lot of gunk and improve failure modes in a number of cases. In particular, we've fixed a bug where other processes could deadlock if they write too much to stderr. Fixes #990
2018-08-30 02:53:52 +02:00
* [BUG #990](https://github.com/BurntSushi/ripgrep/issues/990):
Read stderr asynchronously when running a process.
changelog: massive update for libripgrep This commit updates the CHANGELOG to reflect all the work done to make libripgrep a reality. * Closes #162 (libripgrep) * Closes #176 (multiline search) * Closes #188 (opt-in PCRE2 support) * Closes #244 (JSON output) * Closes #416 (Windows CRLF support) * Closes #917 (trim prefix whitespace) * Closes #993 (add --null-data flag) * Closes #997 (--passthru works with --replace) * Fixes #2 (memory maps and context handling work) * Fixes #200 (ripgrep stops when pipe is closed) * Fixes #389 (more intuitive `-w/--word-regexp`) * Fixes #643 (detection of stdin on Windows is better) * Fixes #441, Fixes #690, Fixes #980 (empty matching lines are weird) * Fixes #764 (coalesce color escapes) * Fixes #922 (memory maps failing is no big deal) * Fixes #937 (color escapes no longer used for empty matches) * Fixes #940 (--passthru does not impact exit status) * Fixes #1013 (show runtime CPU features in --version output)
2018-08-19 16:16:19 +02:00
* [BUG #1013](https://github.com/BurntSushi/ripgrep/issues/1013):
Add compile time and runtime CPU features to `--version` output.
changelog: update This brings the changelog up to date with HEAD and rewords a few things.
2018-08-30 00:25:08 +02:00
* [BUG #1028](https://github.com/BurntSushi/ripgrep/pull/1028):
Don't complete bare pattern after `-f` in zsh.
changelog: massive update for libripgrep This commit updates the CHANGELOG to reflect all the work done to make libripgrep a reality. * Closes #162 (libripgrep) * Closes #176 (multiline search) * Closes #188 (opt-in PCRE2 support) * Closes #244 (JSON output) * Closes #416 (Windows CRLF support) * Closes #917 (trim prefix whitespace) * Closes #993 (add --null-data flag) * Closes #997 (--passthru works with --replace) * Fixes #2 (memory maps and context handling work) * Fixes #200 (ripgrep stops when pipe is closed) * Fixes #389 (more intuitive `-w/--word-regexp`) * Fixes #643 (detection of stdin on Windows is better) * Fixes #441, Fixes #690, Fixes #980 (empty matching lines are weird) * Fixes #764 (coalesce color escapes) * Fixes #922 (memory maps failing is no big deal) * Fixes #937 (color escapes no longer used for empty matches) * Fixes #940 (--passthru does not impact exit status) * Fixes #1013 (show runtime CPU features in --version output)
2018-08-19 16:16:19 +02:00
release: 0.9.0
2018-08-03 22:13:31 +02:00
0.9.0 (2018-08-03)
==================
This is a new minor version release of ripgrep that contains some minor new
features and a panoply of bug fixes.
changelog: update for 0.9.0
2018-03-13 03:46:25 +02:00
release: 0.9.0
2018-08-03 22:13:31 +02:00
Releases provided on Github for `x86_64` will now work on all target CPUs, and
will also automatically take advantage of features found on modern CPUs (such
as AVX2) for additional optimizations.
changelog: update for 0.9.0
2018-03-13 03:46:25 +02:00
deps: bump minimum Rust to 1.23.0 from 1.20.0 1.23.0 is the first Rust release of 2018 and is around half a year old, which seems old enough to move to. This also lets us bring in encoding_rs 0.8, which includes performance optimizations.
2018-07-18 02:29:20 +02:00
This release increases the **minimum supported Rust version** from 1.20.0 to
1.23.0.
release: 0.9.0
2018-08-03 22:13:31 +02:00
It is anticipated that the next release of ripgrep (0.10.0) will provide
multi-line search support and a JSON output format.
changelog: update for 0.9.0
2018-03-13 03:46:25 +02:00
**BREAKING CHANGES**:
* When `--count` and `--only-matching` are provided simultaneously, the
behavior of ripgrep is as if the `--count-matches` flag was given. That is,
the total number of matches is reported, where there may be multiple matches
per line. Previously, the behavior of ripgrep was to report the total number
of matching lines. (Note that this behavior diverges from the behavior of
GNU grep.)
grep: upgrade to regex-syntax 0.5 This update brings with it many bug fixes: * Better error messages are printed overall. We also include explicit call out for unsupported features like backreferences and look-around. * Regexes like `\s*{` no longer emit incomprehensible errors. * Unicode escape sequences, such as `\u{..}` are now supported. For the most part, this upgrade was done in a straight-forward way. We resist the urge to refactor the `grep` crate, in anticipation of it being rewritten anyway. Note that we removed the `--fixed-strings` suggestion whenever a regex syntax error occurs. In practice, I've found that it results in a lot of false positives, and I believe that its use is not as paramount now that regex parse errors are much more readable. Closes #268, Closes #395, Closes #702, Closes #853
2018-03-14 02:38:50 +02:00
* Octal syntax is no longer supported. ripgrep previously accepted expressions
like `\1` as syntax for matching `U+0001`, but ripgrep will now report an
error instead.
changelog: update
2018-04-24 02:01:57 +02:00
* The `--line-number-width` flag has been removed. Its functionality was not
carefully considered with all ripgrep output formats.
See [#795](https://github.com/BurntSushi/ripgrep/issues/795) for more
details.
changelog: update for 0.9.0
2018-03-13 03:46:25 +02:00
Feature enhancements:
changelog: fix typo Fuchsia is a pain to spell. PR #1026
2018-08-23 19:17:27 +02:00
* Added or improved file type filtering for Android, Bazel, Fuchsia, Haskell,
changelog: updates We continue our quest to update the CHANGELOG incrementally.
2018-07-21 20:23:15 +02:00
Java and Puppet.
changelog: update for 0.9.0
2018-03-13 03:46:25 +02:00
* [FEATURE #411](https://github.com/BurntSushi/ripgrep/issues/411):
Add a `--stats` flag, which emits aggregate statistics after search results.
changelog: update
2018-04-24 02:01:57 +02:00
* [FEATURE #646](https://github.com/BurntSushi/ripgrep/issues/646):
Add a `--no-ignore-messages` flag, which suppresses parse errors from reading
`.ignore` and `.gitignore` files.
grep: upgrade to regex-syntax 0.5 This update brings with it many bug fixes: * Better error messages are printed overall. We also include explicit call out for unsupported features like backreferences and look-around. * Regexes like `\s*{` no longer emit incomprehensible errors. * Unicode escape sequences, such as `\u{..}` are now supported. For the most part, this upgrade was done in a straight-forward way. We resist the urge to refactor the `grep` crate, in anticipation of it being rewritten anyway. Note that we removed the `--fixed-strings` suggestion whenever a regex syntax error occurs. In practice, I've found that it results in a lot of false positives, and I believe that its use is not as paramount now that regex parse errors are much more readable. Closes #268, Closes #395, Closes #702, Closes #853
2018-03-14 02:38:50 +02:00
* [FEATURE #702](https://github.com/BurntSushi/ripgrep/issues/702):
Support `\u{..}` Unicode escape sequences.
changelog: update for 0.9.0
2018-03-13 03:46:25 +02:00
* [FEATURE #812](https://github.com/BurntSushi/ripgrep/issues/812):
release: 0.9.0
2018-08-03 22:13:31 +02:00
Add `-b/--byte-offset` flag that shows the byte offset of each matching line.
changelog: update for 0.9.0
2018-03-13 03:46:25 +02:00
* [FEATURE #814](https://github.com/BurntSushi/ripgrep/issues/814):
Add `--count-matches` flag, which is like `--count`, but for each match.
changelog: update
2018-04-24 02:01:57 +02:00
* [FEATURE #880](https://github.com/BurntSushi/ripgrep/issues/880):
Add a `--no-column` flag, which disables column numbers in the output.
ripgrep: add support for lz4 decompression This uses the lz4 binary for decompression. Closes #898
2018-04-27 11:37:53 +02:00
* [FEATURE #898](https://github.com/BurntSushi/ripgrep/issues/898):
Add support for `lz4` when using the `-z/--search-zip` flag.
changelog: updates We continue our quest to update the CHANGELOG incrementally.
2018-07-21 20:23:15 +02:00
* [FEATURE #924](https://github.com/BurntSushi/ripgrep/issues/924):
`termcolor` has moved to its own repository:
https://github.com/BurntSushi/termcolor
ripgrep: add --no-ignore-global flag This commit adds a new --no-ignore-global flag that permits disabling the use of global gitignore filtering. Global gitignores are generally found in `$HOME/.config/git/ignore`, but its location can be configured via git's `core.excludesFile` option. Closes #934
2018-07-22 16:42:32 +02:00
* [FEATURE #934](https://github.com/BurntSushi/ripgrep/issues/934):
Add a new flag, `--no-ignore-global`, that permits disabling global
gitignores.
changelog: updates We continue our quest to update the CHANGELOG incrementally.
2018-07-21 20:23:15 +02:00
* [FEATURE #967](https://github.com/BurntSushi/ripgrep/issues/967):
ripgrep: add --no-ignore-global flag This commit adds a new --no-ignore-global flag that permits disabling the use of global gitignore filtering. Global gitignores are generally found in `$HOME/.config/git/ignore`, but its location can be configured via git's `core.excludesFile` option. Closes #934
2018-07-22 16:42:32 +02:00
Rename `--maxdepth` to `--max-depth` for consistency. Keep `--maxdepth` for
backwards compatibility.
ripgrep: add --pre flag The preprocessor flag accepts a command program and executes this program for every input file that is searched. Instead of searching the file directly, ripgrep will instead search the stdout contents of the program. Closes #978, Closes #981
2018-07-13 15:54:51 +02:00
* [FEATURE #978](https://github.com/BurntSushi/ripgrep/issues/978):
Add a `--pre` option to filter inputs with an arbitrary program.
changelog: updates We continue our quest to update the CHANGELOG incrementally.
2018-07-21 20:23:15 +02:00
* [FEATURE fca9709d](https://github.com/BurntSushi/ripgrep/commit/fca9709d):
Improve zsh completion.
changelog: update for 0.9.0
2018-03-13 03:46:25 +02:00
Bug fixes:
* [BUG #135](https://github.com/BurntSushi/ripgrep/issues/135):
Release portable binaries that conditionally use SSSE3, AVX2, etc., at
runtime.
grep: upgrade to regex-syntax 0.5 This update brings with it many bug fixes: * Better error messages are printed overall. We also include explicit call out for unsupported features like backreferences and look-around. * Regexes like `\s*{` no longer emit incomprehensible errors. * Unicode escape sequences, such as `\u{..}` are now supported. For the most part, this upgrade was done in a straight-forward way. We resist the urge to refactor the `grep` crate, in anticipation of it being rewritten anyway. Note that we removed the `--fixed-strings` suggestion whenever a regex syntax error occurs. In practice, I've found that it results in a lot of false positives, and I believe that its use is not as paramount now that regex parse errors are much more readable. Closes #268, Closes #395, Closes #702, Closes #853
2018-03-14 02:38:50 +02:00
* [BUG #268](https://github.com/BurntSushi/ripgrep/issues/268):
Print descriptive error message when trying to use look-around or
backreferences.
* [BUG #395](https://github.com/BurntSushi/ripgrep/issues/395):
Show comprehensible error messages for regexes like `\s*{`.
changelog: update for 0.9.0
2018-03-13 03:46:25 +02:00
* [BUG #526](https://github.com/BurntSushi/ripgrep/issues/526):
Support backslash escapes in globs.
changelog: update
2018-04-24 02:01:57 +02:00
* [BUG #795](https://github.com/BurntSushi/ripgrep/issues/795):
Fix problems with `--line-number-width` by removing it.
changelog: update for 0.9.0
2018-03-13 03:46:25 +02:00
* [BUG #832](https://github.com/BurntSushi/ripgrep/issues/832):
Clarify usage instructions for `-f/--file` flag.
ignore: speed up Gitignore::empty This commit makes Gitignore::empty a bit faster by avoiding allocation and manually specializing the implementation instead of routing it through the GitignoreBuilder. This helps improve uses of ripgrep that traverse *many* directories, and in particular, when the use of ignores is disabled via command line switches. Fixes #835, Closes #836
2018-04-24 16:42:19 +02:00
* [BUG #835](https://github.com/BurntSushi/ripgrep/issues/835):
Fix small performance regression while crawling very large directory trees.
grep: add "perfect" smart case detection This commit removes the previous smart case detection logic and replaces it with detection based on the regex AST. This particular AST is a faithful representation of the concrete syntax, which lets us be very precise in how we handle it. Closes #851
2018-03-14 03:43:23 +02:00
* [BUG #851](https://github.com/BurntSushi/ripgrep/issues/851):
Fix `-S/--smart-case` detection once and for all.
changelog: update for 0.9.0
2018-03-13 03:46:25 +02:00
* [BUG #852](https://github.com/BurntSushi/ripgrep/issues/852):
Be robust with respect to `ENOMEM` errors returned by `mmap`.
grep: upgrade to regex-syntax 0.5 This update brings with it many bug fixes: * Better error messages are printed overall. We also include explicit call out for unsupported features like backreferences and look-around. * Regexes like `\s*{` no longer emit incomprehensible errors. * Unicode escape sequences, such as `\u{..}` are now supported. For the most part, this upgrade was done in a straight-forward way. We resist the urge to refactor the `grep` crate, in anticipation of it being rewritten anyway. Note that we removed the `--fixed-strings` suggestion whenever a regex syntax error occurs. In practice, I've found that it results in a lot of false positives, and I believe that its use is not as paramount now that regex parse errors are much more readable. Closes #268, Closes #395, Closes #702, Closes #853
2018-03-14 02:38:50 +02:00
* [BUG #853](https://github.com/BurntSushi/ripgrep/issues/853):
release: 0.9.0
2018-08-03 22:13:31 +02:00
Upgrade `grep` crate to `regex-syntax 0.6.0`.
changelog: update
2018-04-24 02:01:57 +02:00
* [BUG #893](https://github.com/BurntSushi/ripgrep/issues/893):
Improve support for git submodules.
ripgrep: when given no patterns, don't match Generally speaking, ripgrep prevents the case of not having any patterns via its arg parsing. However, it is possible for users to provide a file of patterns via the `-f` flag. If that file is empty, then ripgrep has nothing to search for and therefore should not ever produce any match. One way of fixing this might be to replace the absence of patterns with a pattern that can never match, but this still requires opening and searching through every file, which is quite a waste. Instead, we detect this case explicitly and quit early. Fixes #900
2018-07-22 18:07:18 +02:00
* [BUG #900](https://github.com/BurntSushi/ripgrep/issues/900):
When no patterns are given, ripgrep should never match anything.
ripgrep: stop early when --files --quiet is used This commit tweaks the implementation of the --files flag to stop early when --quiet is provided. Fixes #907
2018-07-22 17:05:24 +02:00
* [BUG #907](https://github.com/BurntSushi/ripgrep/issues/907):
ripgrep will now stop traversing after the first file when `--quiet --files`
is used.
ripgrep: don't skip tar archives This removes logic from the decompressor for skipping tar archives. This logic was originally added under the assumption that we probably want to avoid the cost of reading them. However, this is generally inconsistent with how ripgrep treats files like tar archives: it should search them and do binary detection like normal. Fixes #918
2018-07-22 16:57:33 +02:00
* [BUG #918](https://github.com/BurntSushi/ripgrep/issues/918):
Don't skip tar archives when `-z/--search-zip` is used.
ignore: only respect .gitignore in git repos This commit fixes an interesting bug in the `ignore` crate where it would basically respect any `.gitignore` file anywhere (including global gitignores in `~/.config/git/ignore`), regardless of whether we were searching in a git repository or not. This commit rectifies that behavior to only respect gitignore rules when in a git repo. The key change here is to move the logic of whether to traverse parents into the directory matcher rather than putting the onus on the directory traverser. In particular, we now need to traverse parent directories in more cases than we previously did, since we need to determine whether we're in a git repository or not. Fixes #934
2018-07-22 16:29:18 +02:00
* [BUG #934](https://github.com/BurntSushi/ripgrep/issues/934):
Don't respect gitignore files when searching outside git repositories.
changelog: updates We continue our quest to update the CHANGELOG incrementally.
2018-07-21 20:23:15 +02:00
* [BUG #948](https://github.com/BurntSushi/ripgrep/issues/948):
ripgrep: add --no-ignore-global flag This commit adds a new --no-ignore-global flag that permits disabling the use of global gitignore filtering. Global gitignores are generally found in `$HOME/.config/git/ignore`, but its location can be configured via git's `core.excludesFile` option. Closes #934
2018-07-22 16:42:32 +02:00
Use exit code 2 to indicate error, and use exit code 1 to indicate no
matches.
ripgrep: improve usage documentation This shows an example for reading stdin. Fixes #951
2018-07-22 15:38:49 +02:00
* [BUG #951](https://github.com/BurntSushi/ripgrep/issues/951):
Add stdin example to ripgrep usage documentation.
changelog: updates We continue our quest to update the CHANGELOG incrementally.
2018-07-21 20:23:15 +02:00
* [BUG #955](https://github.com/BurntSushi/ripgrep/issues/955):
Use buffered writing when not printing to a tty, which fixes a performance
regression.
ripgrep: better --path-separator error message This commit improves the error message when --path-separator fails. Namely, it prints the separator it got and also prints a notice for Windows users for common failure modes. Fixes #957
2018-07-22 15:32:31 +02:00
* [BUG #957](https://github.com/BurntSushi/ripgrep/issues/957):
Improve the error message shown for `--path separator /` in some Windows
shells.
changelog: updates We continue our quest to update the CHANGELOG incrementally.
2018-07-21 20:23:15 +02:00
* [BUG #964](https://github.com/BurntSushi/ripgrep/issues/964):
Add a `--no-fixed-strings` flag to disable `-F/--fixed-strings`.
* [BUG #988](https://github.com/BurntSushi/ripgrep/issues/988):
Fix a bug in the `ignore` crate that prevented the use of explicit ignore
files after disabling all other ignore rules.
ignore: respect XDG_CONFIG_DIR/git/config This commit updates the logic for finding the value of git's `core.excludesFile` configuration parameter. Namely, we now check `$XDG_CONFIG_DIR/git/config` in addition to `$HOME/.gitconfig` (where the latter overrules the former on a knob-by-knob basis). Fixes #995
2018-07-28 16:04:16 +02:00
* [BUG #995](https://github.com/BurntSushi/ripgrep/issues/995):
Respect `$XDG_CONFIG_DIR/git/config` for detecting `core.excludesFile`.
changelog: update for 0.9.0
2018-03-13 03:46:25 +02:00
changelog: 0.8.1
2018-02-21 03:18:01 +02:00
0.8.1 (2018-02-20)
==================
This is a patch release of ripgrep that primarily fixes regressions introduced
in 0.8.0 (#820 and #824) in directory traversal on Windows. These regressions
do not impact non-Windows users.
Feature enhancements:
* Added or improved file type filtering for csv and VHDL.
* [FEATURE #798](https://github.com/BurntSushi/ripgrep/issues/798):
Add `underline` support to `termcolor` and ripgrep. See documentation on the
`--colors` flag for details.
Bug fixes:
* [BUG #684](https://github.com/BurntSushi/ripgrep/issues/684):
Improve documentation for the `--ignore-file` flag.
* [BUG #789](https://github.com/BurntSushi/ripgrep/issues/789):
Don't show `(rev )` if the revision wasn't available during the build.
* [BUG #791](https://github.com/BurntSushi/ripgrep/issues/791):
Add man page to ARM release.
* [BUG #797](https://github.com/BurntSushi/ripgrep/issues/797):
Improve documentation for "intense" setting in `termcolor`.
* [BUG #800](https://github.com/BurntSushi/ripgrep/issues/800):
Fix a bug in the `ignore` crate for custom ignore files. This had no impact
on ripgrep.
* [BUG #807](https://github.com/BurntSushi/ripgrep/issues/807):
Fix a bug where `rg --hidden .` behaved differently from `rg --hidden ./`.
* [BUG #815](https://github.com/BurntSushi/ripgrep/issues/815):
Clarify a common failure mode in user guide.
* [BUG #820](https://github.com/BurntSushi/ripgrep/issues/820):
Fixes a bug on Windows where symlinks were followed even if not requested.
* [BUG #824](https://github.com/BurntSushi/ripgrep/issues/824):
Fix a performance regression in directory traversal on Windows.
doc: the year is 2018
2018-02-13 01:30:02 +02:00
0.8.0 (2018-02-11)
changelog: 0.8.0
2018-02-11 20:13:15 +02:00
==================
doc: fix typos PR #1605
2020-06-04 15:06:09 +02:00
This is a new minor version release of ripgrep that satisfies several popular
changelog: 0.8.0
2018-02-11 20:13:15 +02:00
feature requests (config files, search compressed files, true colors), fixes
many bugs and improves the quality of life for ripgrep maintainers. This
release also includes greatly improved documentation in the form of a
[User Guide](GUIDE.md) and a [FAQ](FAQ.md).
This release increases the **minimum supported Rust version** from 1.17 to
1.20.
**BREAKING CHANGES**:
Note that these are all very minor and unlikely to impact most users.
* In order to support configuration files, flag overrides needed to be
rethought. In some cases, this changed ripgrep's behavior. For example,
in ripgrep 0.7.1, `rg foo -s -i` will perform a case sensitive search
since the `-s/--case-sensitive` flag was defined to always take precedence
over the `-i/--ignore-case` flag, regardless of position. In ripgrep 0.8.0
however, the override rule for all flags has changed to "the most recent
flag wins among competing flags." That is, `rg foo -s -i` now performs a
case insensitive search.
* The `-M/--max-columns` flag was tweaked so that specifying a value of `0`
now makes ripgrep behave as if the flag was absent. This makes it possible
to set a default value in a configuration file and then override it. The
previous ripgrep behavior was to suppress all matching non-empty lines.
* In all globs, `[^...]` is now equivalent to `[!...]` (indicating class
negation). Previously, `^` had no special significance in a character class.
* For **downstream packagers**, the directory hierarchy in ripgrep's archive
releases has changed. The root directory now only contains the executable,
README and license. There is now a new directory called `doc` which contains
the man page (previously in the root), a user guide (new), a FAQ (new) and
the CHANGELOG (previously not included in release). The `complete`
directory remains the same.
Feature enhancements:
* Added or improved file type filtering for
Apache Avro, C++, GN, Google Closure Templates, Jupyter notebooks, man pages,
Protocol Buffers, Smarty and Web IDL.
* [FEATURE #196](https://github.com/BurntSushi/ripgrep/issues/196):
Support a configuration file. See
[the new user guide](GUIDE.md#configuration-file)
for details.
* [FEATURE #261](https://github.com/BurntSushi/ripgrep/issues/261):
Add extended or "true" color support. Works in Windows 10!
[See the FAQ for details.](FAQ.md#colors)
* [FEATURE #539](https://github.com/BurntSushi/ripgrep/issues/539):
doc: fix typo
2018-02-12 14:16:10 +02:00
Search gzip, bzip2, lzma or xz files when given `-z/--search-zip` flag.
changelog: 0.8.0
2018-02-11 20:13:15 +02:00
* [FEATURE #544](https://github.com/BurntSushi/ripgrep/issues/544):
Add support for line number alignment via a new `--line-number-width` flag.
* [FEATURE #654](https://github.com/BurntSushi/ripgrep/pull/654):
Support linuxbrew in ripgrep's Brew tap.
* [FEATURE #673](https://github.com/BurntSushi/ripgrep/issues/673):
Bring back `.rgignore` files. (A higher precedent, application specific
version of `.ignore`.)
* [FEATURE #676](https://github.com/BurntSushi/ripgrep/issues/676):
Provide ARM binaries. **WARNING:** This will be provided on a best effort
basis.
* [FEATURE #709](https://github.com/BurntSushi/ripgrep/issues/709):
Suggest `-F/--fixed-strings` flag on a regex syntax error.
* [FEATURE #740](https://github.com/BurntSushi/ripgrep/issues/740):
Add a `--passthru` flag that causes ripgrep to print every line it reads.
* [FEATURE #785](https://github.com/BurntSushi/ripgrep/pull/785):
Overhaul documentation. Cleaned up README, added user guide and FAQ.
* [FEATURE 7f5c07](https://github.com/BurntSushi/ripgrep/commit/7f5c07434be92103b5bf7e216b9c7494aed2d8cb):
Add hidden flags for convenient overrides (e.g., `--no-text`).
Bug fixes:
* [BUG #553](https://github.com/BurntSushi/ripgrep/issues/553):
Permit flags to be repeated.
* [BUG #633](https://github.com/BurntSushi/ripgrep/issues/633):
Fix a bug where ripgrep would panic on Windows while following symlinks.
* [BUG #649](https://github.com/BurntSushi/ripgrep/issues/649):
Fix handling of `!**/` in `.gitignore`.
* [BUG #663](https://github.com/BurntSushi/ripgrep/issues/663):
**BREAKING CHANGE:** Support `[^...]` glob syntax (as identical to `[!...]`).
* [BUG #693](https://github.com/BurntSushi/ripgrep/issues/693):
Don't display context separators when not printing matches.
* [BUG #705](https://github.com/BurntSushi/ripgrep/issues/705):
Fix a bug that prevented ripgrep from searching OneDrive directories.
* [BUG #717](https://github.com/BurntSushi/ripgrep/issues/717):
Improve `--smart-case` uppercase character detection.
* [BUG #725](https://github.com/BurntSushi/ripgrep/issues/725):
Clarify that globs do not override explicitly given paths to search.
* [BUG #742](https://github.com/BurntSushi/ripgrep/pull/742):
Write ANSI reset code as `\x1B[0m` instead of `\x1B[m`.
* [BUG #747](https://github.com/BurntSushi/ripgrep/issues/747):
Remove `yarn.lock` from YAML file type.
* [BUG #760](https://github.com/BurntSushi/ripgrep/issues/760):
ripgrep can now search `/sys/devices/system/cpu/vulnerabilities/*` files.
* [BUG #761](https://github.com/BurntSushi/ripgrep/issues/761):
Fix handling of gitignore patterns that contain a `/`.
* [BUG #776](https://github.com/BurntSushi/ripgrep/pull/776):
**BREAKING CHANGE:** `--max-columns=0` now disables the limit.
* [BUG #779](https://github.com/BurntSushi/ripgrep/issues/779):
Clarify documentation for `--files-without-match`.
* [BUG #780](https://github.com/BurntSushi/ripgrep/issues/780),
[BUG #781](https://github.com/BurntSushi/ripgrep/issues/781):
Fix bug where ripgrep missed some matching lines.
Maintenance fixes:
* [MAINT #772](https://github.com/BurntSushi/ripgrep/pull/772):
Drop `env_logger` in favor of simpler logger to avoid many new dependencies.
* [MAINT #772](https://github.com/BurntSushi/ripgrep/pull/772):
Add git revision hash to ripgrep's version string.
* [MAINT #772](https://github.com/BurntSushi/ripgrep/pull/772):
(Seemingly) improve compile times.
* [MAINT #776](https://github.com/BurntSushi/ripgrep/pull/776):
Automatically generate man page during build.
* [MAINT #786](https://github.com/BurntSushi/ripgrep/pull/786):
Remove use of `unsafe` in `globset`. :tada:
* [MAINT e9d448](https://github.com/BurntSushi/ripgrep/commit/e9d448e93bb4e1fb3b0c1afc29adb5af6ed5283d):
Add an issue template (has already drastically improved bug reports).
* [MAINT ae2d03](https://github.com/BurntSushi/ripgrep/commit/ae2d036dd4ba2a46acac9c2d77c32e7c667eb850):
Remove the `compile` script.
Friends of ripgrep:
I'd like to extend my gratitude to
[@balajisivaraman](https://github.com/balajisivaraman)
for their recent hard work in a number of areas, and in particular, for
implementing the "search compressed files" feature. Their work in sketching out
a specification for that and other work has been exemplary.
Thanks
[@balajisivaraman](https://github.com/balajisivaraman)!
changelog 0.7.1
2017-10-22 16:31:26 +02:00
0.7.1 (2017-10-22)
==================
This is a patch release of ripgrep that includes a fix to very bad regression
introduced in ripgrep 0.7.0.
Bug fixes:
* [BUG #648](https://github.com/BurntSushi/ripgrep/issues/648):
Fix a bug where it was very easy to exceed standard file descriptor limits.
changelog 0.7.0
2017-10-22 04:33:23 +02:00
0.7.0 (2017-10-20)
==================
This is a new minor version release of ripgrep that includes mostly bug fixes.
ripgrep continues to require Rust 1.17, and there are no known breaking changes
introduced in this release.
Feature enhancements:
* Added or improved file type filtering for config & license files, Elm,
Purescript, Standard ML, sh, systemd, Terraform
* [FEATURE #593](https://github.com/BurntSushi/ripgrep/pull/593):
Using both `-o/--only-matching` and `-r/--replace` does the right thing.
Bug fixes:
* [BUG #200](https://github.com/BurntSushi/ripgrep/issues/200):
ripgrep will stop when its pipe is closed.
* [BUG #402](https://github.com/BurntSushi/ripgrep/issues/402):
Fix context printing bug when the `-m/--max-count` flag is used.
* [BUG #521](https://github.com/BurntSushi/ripgrep/issues/521):
Fix interaction between `-r/--replace` and terminal colors.
* [BUG #559](https://github.com/BurntSushi/ripgrep/issues/559):
Ignore test that tried reading a non-UTF-8 file path on macOS.
* [BUG #599](https://github.com/BurntSushi/ripgrep/issues/599):
Fix color escapes on empty matches.
* [BUG #600](https://github.com/BurntSushi/ripgrep/issues/600):
Avoid expensive (on Windows) file handle check when using --files.
* [BUG #618](https://github.com/BurntSushi/ripgrep/issues/618):
Clarify installation instructions for Ubuntu users.
* [BUG #633](https://github.com/BurntSushi/ripgrep/issues/633):
Faster symlink loop checking on Windows.
changelog 0.6.0
2017-08-24 01:49:35 +02:00
0.6.0 (2017-08-23)
==================
This is a new minor version release of ripgrep that includes many bug fixes
and a few new features such as `--iglob` and `-x/--line-regexp`.
Note that this release increases the minimum supported Rust version from 1.12
to 1.17.
Feature enhancements:
* Added or improved file type filtering for BitBake, C++, Cabal, cshtml, Julia,
Make, msbuild, QMake, Yocto
* [FEATURE #163](https://github.com/BurntSushi/ripgrep/issues/163):
Add an `--iglob` flag that is like `-g/--glob`, but matches globs
case insensitively.
* [FEATURE #520](https://github.com/BurntSushi/ripgrep/pull/518):
Add `-x/--line-regexp` flag, which requires a match to span an entire line.
* [FEATURE #551](https://github.com/BurntSushi/ripgrep/pull/551),
[FEATURE #554](https://github.com/BurntSushi/ripgrep/pull/554):
`ignore`: add new `matched_path_or_any_parents` method.
Bug fixes:
* [BUG #342](https://github.com/BurntSushi/ripgrep/issues/342):
Fix invisible text in some PowerShell environments by changing the
default color scheme on Windows.
* [BUG #413](https://github.com/BurntSushi/ripgrep/issues/413):
Release binaries on Unix are now `strip`'d by default. This decreases
binary size by an order of magnitude.
* [BUG #483](https://github.com/BurntSushi/ripgrep/issues/483):
When `--quiet` is passed, `--files` should be quiet.
* [BUG #488](https://github.com/BurntSushi/ripgrep/pull/488):
When `--vimgrep` is passed, `--with-filename` should be enabled
automatically.
* [BUG #493](https://github.com/BurntSushi/ripgrep/issues/493):
Fix another bug in the implementation of the `-o/--only-matching`
flag.
* [BUG #499](https://github.com/BurntSushi/ripgrep/pull/499):
Permit certain flags to override others.
* [BUG #523](https://github.com/BurntSushi/ripgrep/pull/523):
`wincolor`: Re-fetch Windows console on all calls.
* [BUG #523](https://github.com/BurntSushi/ripgrep/issues/524):
`--version` now shows enabled compile-time features.
* [BUG #532](https://github.com/BurntSushi/ripgrep/issues/532),
[BUG #536](https://github.com/BurntSushi/ripgrep/pull/536),
[BUG #538](https://github.com/BurntSushi/ripgrep/pull/538),
[BUG #540](https://github.com/BurntSushi/ripgrep/pull/540),
[BUG #560](https://github.com/BurntSushi/ripgrep/pull/560),
[BUG #565](https://github.com/BurntSushi/ripgrep/pull/565):
Improve zsh completion.
* [BUG #578](https://github.com/BurntSushi/ripgrep/pull/578):
Enable SIMD for `encoding_rs` when appropriate.
* [BUG #580](https://github.com/BurntSushi/ripgrep/issues/580):
Fix `-w/--word-regexp` in the presence of capturing groups.
* [BUG #581](https://github.com/BurntSushi/ripgrep/issues/581):
Document that ripgrep may terminate unexpectedly when searching via
memory maps (which can happen using default settings).
Friends of ripgrep:
I'd like to give a big Thank You to @okdana for their recent hard work on
ripgrep. This includes new features like `--line-regexp`, heroic effort on
zsh auto-completion and thinking through some thorny argv issues with me.
I'd also like to thank @ericbn for their work on improving ripgrep's argv
parsing by allowing some flags to override others.
Thanks @okdana and @ericbn!
changelog 0.5.2
2017-05-12 01:05:40 +02:00
0.5.2 (2017-05-11)
==================
Feature enhancements:
* Added or improved file type filtering for Nix.
* [FEATURE #362](https://github.com/BurntSushi/ripgrep/issues/362):
Add `--regex-size-limit` and `--dfa-size-limit` flags.
* [FEATURE #444](https://github.com/BurntSushi/ripgrep/issues/444):
Improve error messages for invalid globs.
Bug fixes:
* [BUG #442](https://github.com/BurntSushi/ripgrep/issues/442):
Fix line wrapping in `--help` output.
* [BUG #451](https://github.com/BurntSushi/ripgrep/issues/451):
Fix bug with duplicate output when using `-o/--only-matching` flag.
changelog 0.5.1
2017-04-09 15:43:16 +02:00
0.5.1 (2017-04-09)
==================
Feature enhancements:
* Added or improved file type filtering for vim.
* [FEATURE #34](https://github.com/BurntSushi/ripgrep/issues/34):
Add a `-o/--only-matching` flag.
* [FEATURE #377](https://github.com/BurntSushi/ripgrep/issues/377):
Column numbers can now be customized with a color. (The default is
no color.)
* [FEATURE #419](https://github.com/BurntSushi/ripgrep/issues/419):
Added `-0` short flag option for `--null`.
Bug fixes:
* [BUG #381](https://github.com/BurntSushi/ripgrep/issues/381):
Include license text in all subcrates.
* [BUG #418](https://github.com/BurntSushi/ripgrep/issues/418),
[BUG #426](https://github.com/BurntSushi/ripgrep/issues/426),
[BUG #439](https://github.com/BurntSushi/ripgrep/issues/439):
Fix a few bugs with `-h/--help` output.
add date to CHANGELOG
2017-03-13 04:31:57 +02:00
0.5.0 (2017-03-12)
==================
changelog 0.5.0
2017-03-13 03:57:50 +02:00
This is a new minor version release of ripgrep that includes one minor breaking
change, bug fixes and several new features including support for text encodings
other than UTF-8.
A notable accomplishment with respect to Rust is that ripgrep proper now only
contains a single `unsafe` use (for accessing the contents of a memory map).
The **breaking change** is:
* [FEATURE #380](https://github.com/BurntSushi/ripgrep/issues/380):
Line numbers are now hidden by default when ripgrep is printing to a tty
**and** the only thing searched is stdin.
Feature enhancements:
* Added or improved file type filtering for Ceylon, CSS, Elixir, HTML, log,
SASS, SVG, Twig
* [FEATURE #1](https://github.com/BurntSushi/ripgrep/issues/1):
Add support for additional text encodings, including automatic detection for
UTF-16 via BOM sniffing. Explicit text encoding support with the
`-E/--encoding` flag was also added for latin-1, GBK, EUC-JP
and Shift_JIS, among others. The full list can be found here:
https://encoding.spec.whatwg.org/#concept-encoding-get
* [FEATURE #129](https://github.com/BurntSushi/ripgrep/issues/129):
Add a new `-M/--max-columns` flag that omits lines longer than the given
number of bytes. (Disabled by default!)
* [FEATURE #369](https://github.com/BurntSushi/ripgrep/issues/369):
A new flag, `--max-filesize`, was added for limiting searches to files with
a maximum file size.
Bug fixes:
* [BUG #52](https://github.com/BurntSushi/ripgrep/issues/52),
[BUG #311](https://github.com/BurntSushi/ripgrep/issues/311):
Tweak how binary files are detected and handled. (We are slightly less
conservative and will no longer use memory without bound.)
* [BUG #326](https://github.com/BurntSushi/ripgrep/issues/326):
When --files flag is given, we should never attempt to parse positional
arguments as regexes.
* [BUG #327](https://github.com/BurntSushi/ripgrep/issues/327):
Permit the --heading flag to override the --no-heading flag.
* [BUG #340](https://github.com/BurntSushi/ripgrep/pull/340):
Clarify that the `-u/--unrestricted` flags are aliases.
* [BUG #343](https://github.com/BurntSushi/ripgrep/pull/343):
Global git ignore config should use `$HOME/.config/git/ignore` and not
`$HOME/git/ignore`.
* [BUG #345](https://github.com/BurntSushi/ripgrep/pull/345):
Clarify docs for `-g/--glob` flag.
* [BUG #381](https://github.com/BurntSushi/ripgrep/issues/381):
Add license files to each sub-crate.
* [BUG #383](https://github.com/BurntSushi/ripgrep/issues/383):
Use latest version of clap (for argv parsing).
* [BUG #392](https://github.com/BurntSushi/ripgrep/issues/391):
Fix translation of set globs (e.g., `{foo,bar,quux}`) to regexes.
* [BUG #401](https://github.com/BurntSushi/ripgrep/pull/401):
Add PowerShell completion file to Windows release.
* [BUG #405](https://github.com/BurntSushi/ripgrep/issues/405):
Fix bug when excluding absolute paths with the `-g/--glob` flag.
changelog 0.4.0
2017-01-14 06:40:11 +02:00
0.4.0
=====
This is a new minor version release of ripgrep that includes a couple very
minor breaking changes, a few new features and lots of bug fixes.
This version of ripgrep upgrades its `regex` dependency from `0.1` to `0.2`,
which includes a few minor syntax changes:
* POSIX character classes now require double bracketing. Previously, the regex
`[:upper:]` would parse as the `upper` POSIX character class. Now it parses
as the character class containing the characters `:upper:`. The fix to this
change is to use `[[:upper:]]` instead. Note that variants like
`[[:upper:][:blank:]]` continue to work.
* The character `[` must always be escaped inside a character class.
* The characters `&`, `-` and `~` must be escaped if any one of them are
repeated consecutively. For example, `[&]`, `[\&]`, `[\&\&]`, `[&-&]` are all
equivalent while `[&&]` is illegal. (The motivation for this and the prior
change is to provide a backwards compatible path for adding character class
set notation.)
Feature enhancements:
* Added or improved file type filtering for Crystal, Kotlin, Perl, PowerShell,
Ruby, Swig
* [FEATURE #83](https://github.com/BurntSushi/ripgrep/issues/83):
Type definitions can now include other type definitions.
* [FEATURE #243](https://github.com/BurntSushi/ripgrep/issues/243):
**BREAKING CHANGE**: The `--column` flag now implies `--line-number`.
* [FEATURE #263](https://github.com/BurntSushi/ripgrep/issues/263):
Add a new `--sort-files` flag.
* [FEATURE #275](https://github.com/BurntSushi/ripgrep/issues/275):
Add a new `--path-separator` flag. Useful in cygwin.
Bug fixes:
* [BUG #182](https://github.com/BurntSushi/ripgrep/issues/182):
Redux: use more portable ANSI color escape sequences when possible.
* [BUG #258](https://github.com/BurntSushi/ripgrep/issues/258):
Fix bug that caused ripgrep's parallel iterator to spin and burn CPU.
* [BUG #262](https://github.com/BurntSushi/ripgrep/issues/262):
Document how to install shell completion files.
Update 0.4.0 changelog. It was missing a change about colors/styles. Fixes #330
2017-01-18 02:33:45 +02:00
* [BUG #266](https://github.com/BurntSushi/ripgrep/issues/266),
[BUG #293](https://github.com/BurntSushi/ripgrep/issues/293):
Fix handling of bold styling and change the default colors.
changelog 0.4.0
2017-01-14 06:40:11 +02:00
* [BUG #268](https://github.com/BurntSushi/ripgrep/issues/268):
Make lack of backreference support more explicit.
* [BUG #271](https://github.com/BurntSushi/ripgrep/issues/271):
Remove `~` dependency on clap.
* [BUG #277](https://github.com/BurntSushi/ripgrep/issues/277):
Fix cosmetic issue in `globset` crate docs.
* [BUG #279](https://github.com/BurntSushi/ripgrep/issues/279):
ripgrep did not terminate when `-q/--quiet` was given.
* [BUG #281](https://github.com/BurntSushi/ripgrep/issues/281):
**BREAKING CHANGE**: Completely remove `^C` handling from ripgrep.
* [BUG #284](https://github.com/BurntSushi/ripgrep/issues/284):
Make docs for `-g/--glob` clearer.
* [BUG #286](https://github.com/BurntSushi/ripgrep/pull/286):
When stdout is redirected to a file, don't search that file.
* [BUG #287](https://github.com/BurntSushi/ripgrep/pull/287):
Fix ZSH completions.
* [BUG #295](https://github.com/BurntSushi/ripgrep/pull/295):
Remove superfluous `memmap` dependency in `grep` crate.
* [BUG #308](https://github.com/BurntSushi/ripgrep/pull/308):
Improve docs for `-r/--replace`.
* [BUG #313](https://github.com/BurntSushi/ripgrep/pull/313):
Update bytecount dep to latest version.
* [BUG #318](https://github.com/BurntSushi/ripgrep/pull/318):
Fix invalid UTF-8 output bug in Windows consoles.
changelog 0.3.2
2016-12-07 17:58:28 +02:00
0.3.2
=====
Feature enhancements:
* Added or improved file type filtering for Less, Sass, stylus, Zsh
Bug fixes:
* [BUG #229](https://github.com/BurntSushi/ripgrep/issues/229):
Make smart case slightly less conservative.
* [BUG #247](https://github.com/BurntSushi/ripgrep/issues/247):
Clarify use of --heading/--no-heading.
* [BUG #251](https://github.com/BurntSushi/ripgrep/issues/251),
[BUG #264](https://github.com/BurntSushi/ripgrep/issues/264),
[BUG #267](https://github.com/BurntSushi/ripgrep/issues/267):
Fix matching bug caused by literal optimizations.
* [BUG #256](https://github.com/BurntSushi/ripgrep/issues/256):
Fix bug that caused `rg foo` and `rg foo/` to have different behavior
when `foo` was a symlink.
* [BUG #270](https://github.com/BurntSushi/ripgrep/issues/270):
Fix bug where patterns starting with a `-` couldn't be used with the
`-e/--regexp` flag. (This resolves a regression that was introduced in
ripgrep 0.3.0.)
changelog 0.3.1
2016-11-22 03:52:42 +02:00
0.3.1
=====
Bug fixes:
* [BUG #242](https://github.com/BurntSushi/ripgrep/issues/242):
ripgrep didn't respect `--colors foo:none` correctly. Now it does.
changelog 0.3.0
2016-11-20 23:06:49 +02:00
0.3.0
=====
This is a new minor version release of ripgrep that includes two breaking
changes with lots of bug fixes and some new features and performance
improvements. Notably, if you had a problem with colors or piping on Windows
before, then that should now be fixed in this release.
**BREAKING CHANGES**:
* ripgrep now requires Rust 1.11 to compile. Previously, it could build on
Rust 1.9. The cause of this was the move from
[Docopt to Clap](https://github.com/BurntSushi/ripgrep/pull/233)
for argument parsing.
* The `-e/--regexp` flag can no longer accept a pattern starting with a `-`.
There are two work-arounds: `rg -- -foo` and `rg [-]foo` or `rg -e [-]foo`
will all search for the same `-foo` pattern. The cause of this was the move
from [Docopt to Clap](https://github.com/BurntSushi/ripgrep/pull/233)
for argument parsing.
[This may get fixed in the
future.](https://github.com/kbknapp/clap-rs/issues/742).
Performance improvements:
* [PERF #33](https://github.com/BurntSushi/ripgrep/issues/33):
ripgrep now performs similar to GNU grep on small corpora.
* [PERF #136](https://github.com/BurntSushi/ripgrep/issues/136):
ripgrep no longer slows down because of argument parsing when given a large
argument list.
Feature enhancements:
* Added or improved file type filtering for Elixir.
* [FEATURE #7](https://github.com/BurntSushi/ripgrep/issues/7):
Add a `-f/--file` flag that causes ripgrep to read patterns from a file.
* [FEATURE #51](https://github.com/BurntSushi/ripgrep/issues/51):
Add a `--colors` flag that enables one to customize the colors used in
ripgrep's output.
* [FEATURE #138](https://github.com/BurntSushi/ripgrep/issues/138):
Add a `--files-without-match` flag that shows only file paths that contain
zero matches.
* [FEATURE #230](https://github.com/BurntSushi/ripgrep/issues/230):
Add completion files to the release (Bash, Fish and PowerShell).
Bug fixes:
* [BUG #37](https://github.com/BurntSushi/ripgrep/issues/37):
Use correct ANSI escape sequences when `TERM=screen.linux`.
* [BUG #94](https://github.com/BurntSushi/ripgrep/issues/94):
ripgrep now detects stdin on Windows automatically.
* [BUG #117](https://github.com/BurntSushi/ripgrep/issues/117):
Colors should now work correctly and automatically inside mintty.
* [BUG #182](https://github.com/BurntSushi/ripgrep/issues/182):
Colors should now work within Emacs. In particular, `--color=always` will
emit colors regardless of the current environment.
* [BUG #189](https://github.com/BurntSushi/ripgrep/issues/189):
Show less content when running `rg -h`. The full help content can be
accessed with `rg --help`.
* [BUG #210](https://github.com/BurntSushi/ripgrep/issues/210):
Support non-UTF-8 file names on Unix platforms.
* [BUG #231](https://github.com/BurntSushi/ripgrep/issues/231):
Switch from block buffering to line buffering.
* [BUG #241](https://github.com/BurntSushi/ripgrep/issues/241):
Some error messages weren't suppressed when `--no-messages` was used.
changelog 0.2.9
2016-11-10 01:52:08 +02:00
0.2.9
=====
Bug fixes:
* [BUG #226](https://github.com/BurntSushi/ripgrep/issues/226):
File paths explicitly given on the command line weren't searched in parallel.
(This was a regression in `0.2.7`.)
* [BUG #228](https://github.com/BurntSushi/ripgrep/issues/228):
If a directory was given to `--ignore-file`, ripgrep's memory usage would
grow without bound.
changelog 0.2.8
2016-11-06 23:16:19 +02:00
0.2.8
=====
Bug fixes:
* Fixed a bug with the SIMD/AVX features for using bytecount in commit
`4ca15a`.
changelog 0.2.7
2016-11-06 22:48:52 +02:00
0.2.7
=====
Performance improvements:
* [PERF #223](https://github.com/BurntSushi/ripgrep/pull/223):
Added a parallel recursive directory iterator. This results in major
performance improvements on large repositories.
* [PERF #11](https://github.com/BurntSushi/ripgrep/pull/11):
ripgrep now uses the `bytecount` library for counting new lines. In some
cases, ripgrep runs twice as fast. Use
`RUSTFLAGS="-C target-cpu=native" cargo build --release --features 'simd-accel avx-accel'`
to get the fastest possible binary.
Feature enhancements:
* Added or improved file type filtering for Agda, Tex, Taskpaper, Markdown,
asciidoc, textile, rdoc, org, creole, wiki, pod, C#, PDF, C, C++.
* [FEATURE #149](https://github.com/BurntSushi/ripgrep/issues/149):
Add a new `--no-messages` flag that suppresses error messages.
Note that `rg foo 2> /dev/null` also works.
* [FEATURE #159](https://github.com/BurntSushi/ripgrep/issues/159):
Add a new `-m/--max-count` flag that limits the total number of matches
printed for each file searched.
Bug fixes:
* [BUG #199](https://github.com/BurntSushi/ripgrep/issues/199):
Fixed a bug where `-S/--smart-case` wasn't being applied correctly to
literal optimizations.
* [BUG #203](https://github.com/BurntSushi/ripgrep/issues/203):
Mention the full name, ripgrep, in more places. It now appears in
the output of `--help` and `--version`. The repository URL is now also
in the output of `--help` and the man page.
* [BUG #215](https://github.com/BurntSushi/ripgrep/issues/215):
Include small note about how to search for a pattern that starts with a `-`.
changelog 0.2.6
2016-11-01 01:59:57 +02:00
0.2.6
=====
Feature enhancements:
* Added or improved file type filtering for Fish.
Bug fixes:
* [BUG #206](https://github.com/BurntSushi/ripgrep/issues/206):
Fixed a regression with `-g/--glob` flag in `0.2.5`.
changelog 0.2.5
2016-10-30 04:44:07 +02:00
0.2.5
changelog 0.2.4
2016-10-30 04:27:39 +02:00
=====
Feature enhancements:
* Added or improved file type filtering for Groovy, Handlebars, Tcl, zsh and
Python.
* [FEATURE #9](https://github.com/BurntSushi/ripgrep/issues/9):
Support global gitignore config and `.git/info/exclude` files.
* [FEATURE #45](https://github.com/BurntSushi/ripgrep/issues/45):
Add --ignore-file flag for specifying additional ignore files.
* [FEATURE #202](https://github.com/BurntSushi/ripgrep/pull/202):
Introduce a new
[`ignore`](https://github.com/BurntSushi/ripgrep/tree/master/ignore)
crate that encapsulates all of ripgrep's gitignore matching logic.
Bug fixes:
* [BUG #44](https://github.com/BurntSushi/ripgrep/issues/44):
ripgrep runs slowly when given lots of positional arguments that are
directories.
* [BUG #119](https://github.com/BurntSushi/ripgrep/issues/119):
ripgrep didn't reset terminal colors if it was interrupted by `^C`.
Fixed in [PR #187](https://github.com/BurntSushi/ripgrep/pull/187).
* [BUG #184](https://github.com/BurntSushi/ripgrep/issues/184):
Fixed a bug related to interpreting gitignore files in parent directories.
changelog 0.2.5
2016-10-30 04:44:07 +02:00
0.2.4
=====
SKIPPED.
changelog 0.2.3
2016-10-12 01:44:50 +02:00
0.2.3
=====
Bug fixes:
* [BUG #164](https://github.com/BurntSushi/ripgrep/issues/164):
Fixes a segfault on macos builds.
* [BUG #167](https://github.com/BurntSushi/ripgrep/issues/167):
Clarify documentation for --threads.
changelog 0.2.2
2016-10-11 04:18:21 +02:00
0.2.2
=====
Packaging updates:
* `ripgrep` is now in homebrew-core. `brew install ripgrep` will do the trick
on a Mac.
* `ripgrep` is now in the Archlinux community repository.
`pacman -S ripgrep` will do the trick on Archlinux.
* Support has been discontinued for i686-darwin.
* Glob matching has been moved out into its own crate:
[`globset`](https://crates.io/crates/globset).
Feature enhancements:
* Added or improved file type filtering for CMake, config, Jinja, Markdown,
changelog 0.2.3
2016-10-12 01:44:50 +02:00
Spark.
changelog 0.2.2
2016-10-11 04:18:21 +02:00
* [FEATURE #109](https://github.com/BurntSushi/ripgrep/issues/109):
Add a --max-depth flag for directory traversal.
* [FEATURE #124](https://github.com/BurntSushi/ripgrep/issues/124):
Add -s/--case-sensitive flag. Overrides --smart-case.
* [FEATURE #139](https://github.com/BurntSushi/ripgrep/pull/139):
The `ripgrep` repo is now a Homebrew tap. This is useful for installing
SIMD accelerated binaries, which aren't available in homebrew-core.
Bug fixes:
* [BUG #87](https://github.com/BurntSushi/ripgrep/issues/87),
[BUG #127](https://github.com/BurntSushi/ripgrep/issues/127),
[BUG #131](https://github.com/BurntSushi/ripgrep/issues/131):
Various issues related to glob matching.
* [BUG #116](https://github.com/BurntSushi/ripgrep/issues/116):
--quiet should stop search after first match.
* [BUG #121](https://github.com/BurntSushi/ripgrep/pull/121):
--color always should show colors, even when --vimgrep is used.
* [BUG #122](https://github.com/BurntSushi/ripgrep/pull/122):
Colorize file path at beginning of line.
* [BUG #134](https://github.com/BurntSushi/ripgrep/issues/134):
Processing a large ignore file (thousands of globs) was very slow.
* [BUG #137](https://github.com/BurntSushi/ripgrep/issues/137):
Always follow symlinks when given as an explicit argument.
* [BUG #147](https://github.com/BurntSushi/ripgrep/issues/147):
Clarify documentation for --replace.
changelog 0.2.1
2016-09-27 02:02:47 +02:00
0.2.1
=====
Feature enhancements:
* Added or improved file type filtering for Clojure and SystemVerilog.
* [FEATURE #89](https://github.com/BurntSushi/ripgrep/issues/89):
Add a --null flag that outputs a NUL byte after every file path.
Bug fixes:
* [BUG #98](https://github.com/BurntSushi/ripgrep/issues/98):
Fix a bug in single threaded mode when if opening a file failed, ripgrep
quit instead of continuing the search.
* [BUG #99](https://github.com/BurntSushi/ripgrep/issues/99):
Fix another bug in single threaded mode where empty lines were being printed
by mistake.
* [BUG #105](https://github.com/BurntSushi/ripgrep/issues/105):
Fix an off-by-one error with --column.
* [BUG #106](https://github.com/BurntSushi/ripgrep/issues/106):
Fix a bug where a whitespace only line in a gitignore file caused ripgrep
to panic (i.e., crash).
changelog 0.2.0
2016-09-26 04:27:58 +02:00
0.2.0
=====
Feature enhancements:
spelling: fix various misspellings These were found by the check spelling action[1] and reported here[2]. PR #1685 [1] - https://github.com/marketplace/actions/check-spelling [2] - https://github.com/jsoref/ripgrep/commit/6f02d056716a116b643da1de4b53c6f15118fc38#commitcomment-42625778
2020-09-22 16:29:16 +02:00
* Added or improved file type filtering for VB, R, F#, Swift, Nim, JavaScript,
changelog 0.2.0
2016-09-26 04:27:58 +02:00
TypeScript
* [FEATURE #20](https://github.com/BurntSushi/ripgrep/issues/20):
Adds a --no-filename flag.
* [FEATURE #26](https://github.com/BurntSushi/ripgrep/issues/26):
Adds --files-with-matches flag. Like --count, but only prints file paths
and doesn't need to count every match.
* [FEATURE #40](https://github.com/BurntSushi/ripgrep/issues/40):
Switch from using `.rgignore` to `.ignore`. Note that `.rgignore` is
still supported, but deprecated.
* [FEATURE #68](https://github.com/BurntSushi/ripgrep/issues/68):
Add --no-ignore-vcs flag that ignores .gitignore but not .ignore.
* [FEATURE #70](https://github.com/BurntSushi/ripgrep/issues/70):
Add -S/--smart-case flag (but is disabled by default).
* [FEATURE #80](https://github.com/BurntSushi/ripgrep/issues/80):
Add support for `{foo,bar}` globs.
Many many bug fixes. Thanks every for reporting these and helping make
`ripgrep` better! (Note that I haven't captured every tracking issue here,
some were closed as duplicates.)
* [BUG #8](https://github.com/BurntSushi/ripgrep/issues/8):
Don't use an intermediate buffer when --threads=1. (Permits constant memory
usage.)
* [BUG #15](https://github.com/BurntSushi/ripgrep/issues/15):
Improves the documentation for --type-add.
* [BUG #16](https://github.com/BurntSushi/ripgrep/issues/16),
[BUG #49](https://github.com/BurntSushi/ripgrep/issues/49),
[BUG #50](https://github.com/BurntSushi/ripgrep/issues/50),
[BUG #65](https://github.com/BurntSushi/ripgrep/issues/65):
Some gitignore globs were being treated as anchored when they weren't.
* [BUG #18](https://github.com/BurntSushi/ripgrep/issues/18):
--vimgrep reported incorrect column number.
* [BUG #19](https://github.com/BurntSushi/ripgrep/issues/19):
ripgrep was hanging waiting on stdin in some Windows terminals. Note that
this introduced a new bug:
[#94](https://github.com/BurntSushi/ripgrep/issues/94).
* [BUG #21](https://github.com/BurntSushi/ripgrep/issues/21):
Removes leading `./` when printing file paths.
* [BUG #22](https://github.com/BurntSushi/ripgrep/issues/22):
Running `rg --help | echo` caused `rg` to panic.
* [BUG #24](https://github.com/BurntSushi/ripgrep/issues/22):
Clarify the central purpose of rg in its usage message.
* [BUG #25](https://github.com/BurntSushi/ripgrep/issues/25):
Anchored gitignore globs weren't applied in subdirectories correctly.
* [BUG #30](https://github.com/BurntSushi/ripgrep/issues/30):
Globs like `foo/**` should match contents of `foo`, but not `foo` itself.
* [BUG #35](https://github.com/BurntSushi/ripgrep/issues/35),
[BUG #81](https://github.com/BurntSushi/ripgrep/issues/81):
When automatically detecting stdin, only read if it's a file or a fifo.
i.e., ignore stdin in `rg foo < /dev/null`.
* [BUG #36](https://github.com/BurntSushi/ripgrep/issues/36):
Don't automatically pick memory maps on MacOS. Ever.
* [BUG #38](https://github.com/BurntSushi/ripgrep/issues/38):
Trailing whitespace in gitignore wasn't being ignored.
* [BUG #43](https://github.com/BurntSushi/ripgrep/issues/43):
--glob didn't work with directories.
* [BUG #46](https://github.com/BurntSushi/ripgrep/issues/46):
Use one fewer worker thread than what is provided on CLI.
* [BUG #47](https://github.com/BurntSushi/ripgrep/issues/47):
--help/--version now work even if other options are set.
* [BUG #55](https://github.com/BurntSushi/ripgrep/issues/55):
ripgrep was refusing to search /proc/cpuinfo. Fixed by disabling memory
maps for files with zero size.
* [BUG #64](https://github.com/BurntSushi/ripgrep/issues/64):
The first path given with --files set was ignored.
* [BUG #67](https://github.com/BurntSushi/ripgrep/issues/67):
Sometimes whitelist globs like `!/dir` weren't interpreted as anchored.
* [BUG #77](https://github.com/BurntSushi/ripgrep/issues/77):
When -q/--quiet flag was passed, ripgrep kept searching even after a match
was found.
* [BUG #90](https://github.com/BurntSushi/ripgrep/issues/90):
Permit whitelisting hidden files.
* [BUG #93](https://github.com/BurntSushi/ripgrep/issues/93):
ripgrep was extracting an erroneous inner literal from a repeated pattern.
Reference in New Issue Copy Permalink