Expand glob paths on Windows

[troplin]

On Windows, glob expansion is not done by the shell (cmd.exe), but left to the individual program.
That means, that currently something like this doesn't work:

>rg PATTERN *.txt
*.txt: The filename, directory name, or volume label syntax is incorrect. (os error 123)
No files were searched, which means ripgrep probably applied a filter you didn't expect. Try running again with --debug.

It tries to open a file called *.txt, which obviously doesn't exist.

[BurntSushi]

What do other command line tools like grep do?

[troplin]

grep does work as expected for me.
I installed it with cygwin though, so I'm not sure if this is a cygwin or grep feature.

But all native Windows tools I know do the expansion themselves, at least if it makes sense to expand.

[troplin]

Usually you just use FindFirstFile/FindNextFile for this.
Not sure if it uses the exact same rules as unix glob.

[BurntSushi]

sigh Indeed, it looks like globbing is done as part of the command line program: https://cygwin.com/ml/cygwin/2009-12/msg01097.html

Other instances of the same problem:

• emscripten-core/emscripten#1675
• http://stackoverflow.com/questions/11557280/filename-globbing-windows-vs-unix

I think what this means is that I need to add a glob iterator to globset. Alternatively, we could use the existing iterator in the glob crate, but it doesn't support {a,b} syntax and gets some non-UTF-8 corner cases wrong.

[BurntSushi]

I think what this means is that I need to add a glob iterator to globset. Alternatively, we could use the existing iterator in the glob crate, but it doesn't support {a,b} syntax and gets some non-UTF-8 corner cases wrong.

The other other alternative is to use the standard Windows APIs for this. It seems like the kinds of globs it supports are not as nice as Unix-style globbing, but perhaps that's what Windows users expect, so it could be defensible to use that.

I don't anticipate working on this soon unfortunately.

[troplin]

I thinks using the Windows API is better than nothing and probably easier to implement.
I might give it a try if I find the time.

[BurntSushi]

@troplin Thanks! If you do, I would hope to see the Windows logic put behind a separate crate. :-) (Which could live inside ripgrep, or could be yours to maintain.)

[BurntSushi]

Question: should ripgrep support Unix-style globbing here, or should it use the standard FindFirstFile/FindNextFile APIs, presumably to be consistent with other Windows CLI tools?

cc @retep998 @roblourens

[roblourens]

Do the windows APIs support anything besides * and ?? It's not clear.

This doesn't affect vscode scenarios, but as a CLI user, I'd prefer more powerful patterns.

[sabi0]

How about -g <GLOB> using Unix-style globs (as it does already) and just <GLOB> falling back to Windows API?

Basically there is already such behavior separation between ripgrep and shell globbing on Linux. And Windows CLI is just an "inferior shell" one might argue. So it would be natural for (emulated) "shell globbing" to work in the shell native way.

[HerbM]

FYI:
cmd.exe does NOT support anything but * and ? (specifically NOT [a-z] character classes).
PowerShell does support the character classes as part of "wildcards" (what it calls Globbing.

Current -g switch in RipGrep seems to work fine with ?, *, [class]

It does NOT work without the -g (which is as designed but a bit unexpected for a Windows only user.)

Worth putting out a Windows specific warning when the last thing on the line is *.txt or similar and nothing to search, instead of the current warning:

*.txt: The filename, directory name, or volume label syntax is incorrect. (os error 123)

Maybe add,

use '-g FilePattern' for globbing (wildcard file patterns)