-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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,path/filepath: clarify that patterns don't conform to the POSIX Shell spec #23456
Comments
I forgot to mention that this also likely applies to its counterpart in |
The implementation and documentation of Match make no claim to be POSIX-compatible. The patterns it accepts are fully defined, and if the pattern is bad, it reports an error. Match is working as intended, in my opinion. Moreover, changing its behavior would be a breaking change. You are free to provide an alternate implementation outside the standard library. |
I agree that path.Match is working as documented. I think the godoc mentioning "the shell file name pattern" might be misleading though. I think it's understandable that users may think "the shell" would refer to their OS's shell (particularly for package path/filepath, which behaves "in a way compatible with the target operating system-defined file paths"). Perhaps replace "shell" with "glob" (ErrBadPattern refers to "globbing patterns")? Or just remove "shell" altogether and refer to them simply as "file name patterns"? |
Yes, that CL is somewhat related. One made me come up with the other. I thought about simply changing the godoc. But I was wondering if it was simply buggy software, given how the godoc clearly mentioned shells. Dropping "shell" is an option, but that could make the APIs harder to find for users. Perhaps a distinction saying that this is a different syntax than POSIX/bash would be enough. That warning underneath the syntax definition in the godoc would have left it clear to me that the differences are by design. I think glob is a bad term to settle for, though. See the CL for the reasoning. |
This came up earlier too: #13396 |
Thanks, @0xmohit. It seems clear that the changes will be rejected unanimously, then. In that case, I propose to add the clarification that I mentioned above. I'll modify the CL to include it, and repurpose the issue. |
path doesn't even claim to be for file systems. filepath defines the pattern precisely. It doesn't need to say its not POSIX. It also doesn't say its not Windows. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes.
What did you do?
Use some shell patterns with
path.Match
.https://play.golang.org/p/aTUkgwmS-Z6
What did you expect to see?
What did you see instead?
For reference, this is a program one can use with Bash to reproduce the expected output:
There are three small issues here. I'll be quoting the POSIX spec that covers bracket expressions, as seen in 9.3.5: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_03_05
In order:
]
should not have special meaning if it's the first in the list. This is not done properly, as can be seen by the[]ab]
test case. Quoting:-
should not have special meaning if it's the first or last in the list. The relevant test case is[-ab]
. Quoting:[\ab]
(Bash source needs double quoting to get the correct pattern). Quoting:I know that not all POSIX Shell pattern matching rules are implemented, like collating symbols and locale. However, these seem like fairly basic stuff that would be easy to fix. I am more than happy to submit patches to fix these in Go 1.11.
The first two changes would simply fix some patterns that used to error. All programs working today would continue to work.
The third change is a bit trickier. If someone is using
[\ab]
as a pattern nowadays, it currently means "a
, orb
". But with the change, it would then mean "\
, ora
, orb
" (as in a shell pattern match). This could potentially break some programs.I would argue that we should apply the third change anyway. The change can be carefully noted in the release notes, and the previous behavior is likely confusing users that expect pattern matching to work like in the shell. I realise that the syntax is specified in the godoc, but still.
The text was updated successfully, but these errors were encountered: