Skip to content
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

Documentation for **/ is confusing #47

Open
brprice opened this issue Mar 3, 2022 · 1 comment
Open

Documentation for **/ is confusing #47

brprice opened this issue Mar 3, 2022 · 1 comment

Comments

@brprice
Copy link

brprice commented Mar 3, 2022

The docs say "**/ Matches any number of characters, including path separators, excluding the empty string.", but this does not seem to match what I see in practice.

I see the following, where each M is a file

$ tree
.
├── A
│   └── M
├── B
│   ├── C
│   │   └── M
│   └── M
└── M

With zsh, for comparison, as that is what I traditionally associate this syntax with

$ echo **/
A/ B/ B/C/
$ echo **/M
A/M B/C/M B/M M

With Glob

System.FilePath.Glob> globDir1 (compile "**/") "."
["./A/","./B/"]
System.FilePath.Glob> globDir1 (compile "**/M") "."
["./A/M","./B/M","./B/C/M","./M"]
System.FilePath.Glob> match (compile "**/M") "M"
True
System.FilePath.Glob> match (compile "**/") "B/C/"
True

Notice:

  • (**/M matches the same as zsh does on this example)
  • (**/ does not behave the same as zsh)
  • **/M matches M (seeming to show that **/ can match the empty string)
  • **/ only picks up A and B and not B/C/ when running via globDir1, but **/ matches the string B/C/ (but not B/C)
  • **/ does not match any files!

The behaviour seems to be more akin to **/ will match any (potentially empty) sequence of directories, but may or may not match nested directories/be recursive based on some subtle details". This seems rather weird, so I doubt this is the actual behaviour. Some clarification on what this pattern does would be appreciated.

@Deewiant
Copy link
Owner

Deewiant commented Mar 7, 2022

In addition to the documentation, it seems that the behaviour is wrong.

That first globDir1 should certainly return ./B/C/ as well; in general globDir1 pat should correspond exactly to a filter (match pat) over a recursive directory listing.

**/M matching "M" feels wrong, though I can't say for sure whether there may have been a reason for it. As you point out, it conflicts with the documentation at the very least.

In general zsh was the inspiration for the default behaviour so any conflicts are more likely than not to be a bug in Glob.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants