Path separator insensitive with wildcards

[tboby]

I'm having some trouble using wildcard globs in situations where I get mixed forward and backward slashes (cross-platform vscode extension, it's a nightmare, vscode gives you wonderful things like //c/users)

"**/gfx/*.gfx" seems to work fine on mixed slashes.

"**/gfx/**/*.gfx" only seems to work on paths with forward slashes.

"**\\gfx\\**\\*.gfx" only seems to work on paths with backwards slashes.

Is this working as designed, or am I missing something?

[dazinator]

Looks like an issue. Next chance I get I will add these test cases and investigate. Thanks for reporting!

[dazinator]

"*/gfx/.gfx" seems to work fine on mixed slashes.

Really?

I am matching **/gfx/*.gfx against HKEY_LOCAL_MACHINE\gfx\foo.gfx and that fails too! Do you have any concrete examples where it matches mixed slashes?

[tboby]

        var glob = Glob.Parse("**/gfx/*.gfx");
        Console.WriteLine(glob.IsMatch("test\\gfx/test.gfx").ToString());

Outputs True, :)

So does glob.IsMatch("test\\gfx\\test.gfx")

[dazinator]

Ah ok. Just to confirm - are you setting any other glob options such as:

            GlobParseOptions.Default.Parsing.AllowInvalidPathCharacters = true;

?

[tboby]

In that example, no, https://dotnetfiddle.net/h8mBRQ

In my actual use I use CaseInsensitive = true now I believe. But this issue existed before 2.0.

[dazinator]

So I have discovered #47 - not sure whether that is the root cause but it is certainly an issue. Will get that fixed, and then will continue to add more test cases for this issue

[dazinator]

So it does look like there is an issue with the /** token matching.

For some reason I deliberately made it so if you use /** the slash is matched literally. So \** and /** are sensitive to the slash direction!

Thinking about it now, I cannot think why that might be desirable.

Unless you actually care about the difference? But given that the ordinary path seperator token in say patterns like foo/bar are not sensitive at the moment this inconsistency is confusing.

To rectify I think I will make it insensitive which should solve your issue. If sensitivity is needed in the future, I can add an option for it if someone raises an issue.

[tboby]

My expectation would be that everything is path separator insensitive by default, yeah. Just for context I currently have lists like this which is easy for me to mess up. https://github.com/tboby/cwtools/blob/master/CWTools/Game/ResourceManager.fs#L195-L205

I guess the main thing is the api has .PathSeparator() and I think it would be normal to expect to be insensitive. However currently you can't do that via .Parse()? Thanks for looking into this, super useful library!

[dazinator]

My expectation would be that everything is path separator insensitive by default, yeah.

Agreed. Once appveyor builds and publishes to nuget, please give version 2.0.2 a whirl and let me know!

However currently you can't do that via .Parse()?

.PathSeparator() captures the direction of the path seperator for a couple of reasons - even if the actual match is insensitive. The first reason is that if you parse /foo\\bar into a glob, and then do ToString() on that, it has enough information to produce the originally parsed pattern string i.e /foo\\bar. Second reason is that in future versions, I can more easily add in an option to turn on "senstive" path seperator matching, as the information about the path seperator direction is being captured. Whether or not that will actually end up a feature yet, remains to be seen :-)