Fix: strip standalone "." directory path #2711
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The problem is that in Ignore::matched, the perfix "./" is stripped from files. In Ignore::matched_ignore, the directory path is then stripped from file paths. Now imagine we have a hidden file "./.foo" and pass "." as the search path. "./.foo" gets first stripped to ".foo" and then it would have been stripped to "foo".
1 task
tmccombs
added a commit
to tmccombs/fd
that referenced
this pull request
Mar 14, 2024
This is a workaround for BurntSushi/ripgrep#2711 Fixes: sharkdp#1461
tmccombs
added a commit
to tmccombs/fd
that referenced
this pull request
Mar 14, 2024
This is a workaround for BurntSushi/ripgrep#2711 Fixes: sharkdp#1461
sharkdp
pushed a commit
to sharkdp/fd
that referenced
this pull request
Apr 30, 2024
This is a workaround for BurntSushi/ripgrep#2711 Fixes: #1461
netbsd-srcmastr
pushed a commit
to NetBSD/pkgsrc
that referenced
this pull request
May 6, 2024
v10.0.0 Features - Add `dir` as an alias to `directory` when using `-t` \ `--type`, see #1460 and #1464 (@Ato2207). - Add support for @%s date format in time filters similar to GNU date (seconds since Unix epoch for --older/--newer), see #1493 (@nabellows) - Breaking: No longer automatically ignore `.git` when using `--hidden` with vcs ignore enabled. This reverts the change in v9.0.0. While this feature was often useful, it also broke some existing workflows, and there wasn't a good way to opt out of it. And there isn't really a good way for us to add a way to opt out of it. And you can easily get similar behavior by adding `.git/` to your global fdignore file. See #1457. Bugfixes - Respect NO_COLOR environment variable with `--list-details` option. (#1455) - Fix bug that would cause hidden files to be included despite gitignore rules if search path is "." (#1461, BurntSushi/ripgrep#2711). - aarch64 builds now use 64k page sizes with jemalloc. This fixes issues on some systems, such as ARM Macs that have a larger system page size than the system that the binary was built on. (#1547) - Address [CVE-2024-24576](https://blog.rust-lang.org/2024/04/09/cve-2024-24576.html), by increasing minimum rust version. Changes - Minimum supported rust version is now 1.77.2 On pkgsrc this has been reverted as CVE-2024-24576 only affects Windows.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The problem is that in Ignore::matched, the perfix "./" is stripped from files. In Ignore::matched_ignore, the directory path is then stripped from file paths. Now imagine we have a hidden file "./.foo" and pass "." as the search path. "./.foo" gets first stripped to ".foo" and then it would have been stripped to "foo".
I am not completely sure though whether this is the best way to fix it. One could also check earlier whether the directory path is "." and then change it to "./". I don't know which is the best way regarding performance; the current fix is just at the place where it breaks. What do you think?
The implications of this problem (at least the ones I noticed) are that when grepping (including hidden files and passing
.as search directory) in a subdirectorya/bofa, andbhas a hidden file.foo, which is ignored in a ignore file ina, the contents of.fooare shown.I put in https://github.com/taeruh/debug_file_paths a minimal debugging example to show that.
Issue #829 is similar, but I am not sure about how much it is related.