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: Glob should support **
for zero or more directories
#11862
Comments
For reference, here is Rust's implementation. I think these rules would be a good description of how Go's filepath.Glob should work: https://github.com/rust-lang/glob/blob/master/src/lib.rs#L369 |
**
for zero or more directories**
for zero or more directories
For reference, this is supported by bash when invoked as "bash -O globstar" or after running "shopt -s globstar". |
**
for zero or more directories**
for zero or more directories
Added --exclude option that mimics ctag's exclude flag. The pattern is expected to be a shell glob pattern (which is what Go's filepath.Match method expects). It can be set multiple times to set several filters. Once the file list is built, the patterns will be applied to each file to filter out any names that match the exclude patterns before processing. Note: Glob pattern '**' does not work recursively. See open issue golang/go#11862
OK to implement? @adg |
@bradfitz for opinion |
I think this is OK to implement. |
Yep, I agree. |
CL https://golang.org/cl/16280 mentions this issue. |
all, I wanted to check in to see if this issue (#11862) was fixed. Please let me know status of this ticket. Is there a work around to this problem? Talk to you soon. Thanks in advance. |
Status: currently I'm not working on this. Feel free to unassign. |
I certainly see the utility here but adding |
@rsc closed the most recent CL for this with the comment:
Should this issue remain open? |
This issue does remain open. What's confusing is that GitHub has linked just above your comment to issue Shopify/themekit#102, which is closed. |
@rsc that is because someone linked to it in a Markdown link / comment: Shopify/themekit#102 (comment) What can be done here? A better implementation? It's not clear to me. |
I think it's useful, but I wouldn't consider it backwards compatible. |
@extemporalgenome At best, I'd argue that |
@slimsag the shopify issue I think is different. They chose to walk the tree and that solved their case - I don't think that applies to the general problem. I think @rsc was saying that the solution here is non trivial (and it's not just I'd like it to stay on the list. Coming from other languages, I think this is a pretty common feature for glob syntax. Note that the downside of attempting to write your own implementation is that I think you would wind up re-implementing glob entirely. I'm trying to figure out how to solve this for http://github.com/jstemmer/gotags since it won't be solved in the standard library anytime soon. |
@ascarter The proposed special-casing of |
I'm thinking this feature should be provided from third-party products not core. |
go's native implementation is broken: golang/go#11862
Stopgap WorkaroundThis may not be a perfect solution, but weighing in at only 60 LoC it's a good start for those willing to use something outside of the standard library: |
The main problem was that the file exists checker uses go's built in filepath globber, which doesn't support double-asterisk patterns (golang/go#11862). Additionally, with patterns like `*.js` we need to search for all JS files not only on the first level but also in nested directories. Based on made investigation this problem was fixed and additional test covereage was added to document that contract.
The main problem was that the file exists checker uses go's built-in filepath globber, which doesn't support double-asterisk patterns (golang/go#11862). Additionally, with patterns like `*.js` we need to search for all JS files not only on the first level but also in nested directories. Based on made investigation this problem was fixed and additional test coverage was added to document that contract. * Refactor code to remove lint issues * Update Go min version to 1.14 on CI
Go's glob patterns do not treat "**" as meaning "all directories below, recursively." Instead, "**" means the same as "*". So shared/**/*.tmpl is legal but retrieves only files that are one level down from "shared". Currently this isn't a problem, but it would be if a subdirectory of "shared" had its own subdirectory with *.tmpl files. Remove the "**" to make this clear. Change-Id: Ia57212eb55347705af49e2e42cbe9948e14370be Reviewed-on: https://go-review.googlesource.com/c/pkgsite/+/359034 Trust: Jonathan Amsterdam <jba@google.com> Run-TryBot: Jonathan Amsterdam <jba@google.com> TryBot-Result: kokoro <noreply+kokoro@google.com> Reviewed-by: Julie Qiu <julie@golang.org> Reviewed-by: Jamal Carvalho <jamal@golang.org>
In general I agree that a function's documentation should say what it does and not what it doesn't do. But using
We could word the doc so that it describes a consequence of the function's behavior, instead of describing non-behavior. For example, "Note that multiple consecutive |
Could this be needed to match only
|
@mih-kopylov There are some concerns that Russ outlined in an earlier comment and also there are compatibility promises that we must heed. So if someone wants to address this issue they need should probably write it up as a proposal that addresses all these potential issues. In the meantime, if there is a (seemingly, from my brief research) mature doublestar package that provides a glob that handles |
for the feature branch delta detection, we need a glob like syntax in the config file which can be matched against the current diff between a feature and the default branch in gitlab. Because golangs internal file path match is broken (golang/go#11862) is seems to be necessary to use an external lib. go-zglob does this very well, so use it.
Go version 1.4.2
Mac OS X 10.10
Example:
Expected:
Actual:
It seems that
**
is equivalent to*
. The extended**
pattern is common in shells and is supported in Rust and Java for example.The text was updated successfully, but these errors were encountered: