Improve Windows support for escaped glob syntax #12718
Closed
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.
This PR is a continuation of #12715 to apply the same improvements for Windows.
On Windows the path separator is
\\
and\\
is also used for escaping the[
,]
,(
and)
characters. This will result in\\\\[
for example. In this case it means that the first\\
is the path separator and the second\\
is the escape for the[
or(
characters.Additionally, we also ensure that we only escape
[
,]
and(
,)
when the balanced pairs are both not escaped yet. Right now it was going over the individual characters and escaping them accordingly.This is not enough, because in case of this path:
The first
\\[
looks like it is escaped, but on Windows this is just the path separator. Thefoo]
part is not escaped therefor we should escape the whole thing. As a first step, this will result in:Now we do have the 4 backslashes
\\\\
, then in the normalization step, we normalize\\
to/
. If we do this as is, then it would look like this, which is also incorrect:... it's incorrect because we have
/[foo/]
and we expected/\\[foo\\]
instead.If we apply the logic I mentioned earlier where the first
\\
is the path separator and the second\\
is the escape, then we can convert:... to this first:
Then we can apply the rest of the normalization, which looks like this:
... and now the
[foo]
part is properly escaped as\\[foo\\]
.