The reason is because someone hasn't worked on it yet. The reality is that Windows leaves glob expansion up to the CLI tool itself, where as the shell in a Unix environment does glob expansion before invoking the executable. On top of that, there appears to be no consensus on whether ripgrep should use standard Windows APIs to expand globs (which are much much less expressive than Unix-style globs), or to just implement its own globbing. There is a ticket tracking it: https://github.com/BurntSushi/ripgrep/issues/234
I've done a lot of work to make ripgrep work well on Windows. But haven't done this. You can usually work around it pretty easily with the -g flag. e.g.,
Thanks, soms interesting inside-baseball lore there. I should probably just suck it and get used to the -g syntax, I guess. It does seem like a superb grep implementation.
I'm a Windows user, so I consider myself lucky that it works at all. :) As a class, we have been conditioned not to expect or demand too much from command-line utilities from the Unix family tree.
I'm basically looking to maintain the same functionality that was available under DOS with Borland's Turbo Grep in the late 1980s. Those old DOS function calls are still emulated in Win32 as far as I know, but a current implementation would normally use FindFirstFile / FindNextFile like so:
C8 name_buffer[MAX_PATH];
strcpy(name_buffer,dir_buffer); // directory to scan, if not CWD
strcat(name_buffer,filespec); // MS-DOS style filespec with optional * and/or ? wildcards (obviously use snprintf, etc. for this, not strcpy/strcat)
HANDLE search_handle;
WIN32_FIND_DATA found;
search_handle = FindFirstFile(name_buffer, &found);
if (search_handle != INVALID_HANDLE_VALUE)
{
do
{
if (found.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
{
continue;
}
strcpy(name_buffer, dir_buffer);
strcat(name_buffer, found.cFileName);
// name_buffer now indicates a single file
// which can be opened with fopen or
// CreateFile or whatever
}
while (FindNextFile(search_handle, &found));
FindClose(search_handle);
}
There's probably already some code like this in the area of the program that's used to implement the -g mechanism for types. The latter seems a bit overengineered when I'm just looking for wildcard expansion, but I can see it being useful in a lot of cases. It just shouldn't be the only way to constrain the file set, IMO. A new syntax isn't expected or desired, at least not by me, as long as the old one works.
I've done a lot of work to make ripgrep work well on Windows. But haven't done this. You can usually work around it pretty easily with the -g flag. e.g.,
or even shorter