New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
path/filepath: always validate full Glob patterns #28614
Comments
An alternative: make Match evaluate pattern non-lazily. That way there would be no risk that the implementations will diverge and Match will return an error for pattern which passes IsPatternValid. |
Per discussion with @golang/proposal-review, we believe that the |
@andybons I certainly like that the current implementation is as efficient as possible. I just miss the option to validate a pattern. Maybe calling Alternatively there could be |
Hi, I've been checking this issue and I would like to work on it if no one else is doing it right now as my first contribution. I see two possible implementations using the same functions.
As per your previous conversation, you seem more inclined to the second option, right? Thanks, |
We want to make sure that implementation is simple, efficient, and always detects an invalid pattern. I would tend to think that the second option you list is likely to be the better approach, but I think we're open to any implementation that meets those goals as best as possible. Thanks. |
Change https://golang.org/cl/186937 mentions this issue: |
@ianlancetaylor I've created a PR (https://go-review.googlesource.com/c/go/+/186937) with a possible implementation for Thanks, |
The current implementation of the glob in Match(pattern, name) function is evaluating the pattern syntax in a lazy way, this can lead to some mistakes, due to a call with an invalid pattern can end up without match or returning ErrBadPattern error depending on the input. This change forces the pattern syntax validation, avoiding inconsistent error return depending on the input, this change shouldn't break the compatibility even without the correct error handling but can imply a performance penalty when the input is empty. Fixes golang#28614 Change-Id: I055a3b707b93f8ddda87551effb90f5e767a4117 GitHub-Last-Rev: 2099052 GitHub-Pull-Request: golang#33189
Change https://golang.org/cl/224900 mentions this issue: |
Change https://golang.org/cl/224997 mentions this issue: |
Change https://golang.org/cl/264397 mentions this issue: |
The functions
filepath.Match(pattern, name)
andpath.Match(pattern, name)
returnErrBadPattern
if the pattern is invalid, but due to lazy evaluation the error may or may not occur depending on what you match.Example:
As patterns are often user input, it would be handy to be able to validate the pattern. If the validation is successful, it should be guaranteed that
filepath.Match()
will not return an error.I created a PR for this here and was asked to open a proposal issue first.
Other programming languages seem to either not validate the pattern at all (like Python's
glob.glob('a[')
), or always validate the pattern (like Java'sFileSystems.getDefault().getPathMatcher("glob: a["))
). I couldn't find an example where validation depends on what name is matched.The text was updated successfully, but these errors were encountered: