Match escaped square brackets in paths literally not as regexes #1306
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 is an experiment looking at issue #838 which fails to find file with names containing square brackets. As discussed in that issue square brackets are usually interpreted as regexes and we'd rather not add an extra kwarg throughout the API to specify whether regex or literal interpretation should apply.
So one option is to escape the square brackets using backslashes. That doesn't work on the
master
branch, but after this one-line addition it does work. Test script:which using this PR gives
This isn't complete, it doesn't deal with anything other than square brackets and it causes some existing tests to fail.
Alternative implementations are possible. There are quite a lot of lines of string and regex processing around the change, and these could no doubt be modified to include the new behaviour but I would be wary of doing so and causing other failures elsewhere.
There is a certain irony that the one line change to force the behaviour to not be a regex is itself a regex in which the important characters have to be escaped to be interpreted correctly!