pattern: wrong results for /**foo
#1149
Comments
|
We aim to emulate Bash behavior as closely as possible within reason, so this is likely a bug. The recursive globbing logic is surprisingly difficult to get exactly right. Happy to review a patch, otherwise I'll look at this sometime this week. |
mvdan
added a commit
that referenced
this issue
Apr 13, 2025
Bash documents globstar as follows:
When the globstar shell option is enabled, and * is used in a
pathname expansion context, two adjacent *s used as a single pattern
will match all files and zero or more directories and subdirectories
That is, `/**/foo` or `bar/**` both result in globstar globbing
where we can match files and nested directories,
but `/**foo` or `bar**/` do not place the two star characters
in a single pattern, so they behave like a single glob star instead.
The interp and expand packages already deals with this correctly,
because they first split the glob pattern into path elements,
and they deal with one element being exactly "**" in a special way.
The pattern package still aims to support "**" by itself,
but it does not handle this edge case properly;
it treats any occurrence of "**" as a globstar wildcard no matter
whether or not it's on its own as a path element.
Fix coming in the next commit.
For #1149.
|
This should be fixed now. See the commit adding test cases; this wasn't a bug in the |
|
Thanks for working on this so quickly! This looks right to me... |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
While working on #1147 I think I noticed that the regexp generated for
/**foois incorrect.https://go.dev/play/p/XXoRQ4EdBwV is some go code that matches
/**fooagainst a number of paths; as you can see all three match.Here's a bash shell in a container testing the same three paths:
Bash only matches
/foo, the pattern package matches all three paths. Is this a bug or am I missing something?The text was updated successfully, but these errors were encountered: