-find returns unexpected results

[TrebuchKill]

Using -find with for example **\cl.exe returns in my case the expected multiple results, like Hostx64\x64\cl.exe and Hostx86\x64\cl.exe.
Additionally, it returns an unexpected result: Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\Git\usr\bin\getfacl.exe.

Based on the description (option: -h) I expect only cl.exe in any directory to be returned with **\cl.exe as the argument to -find. getfacl.exe does not fit this criterion.

**\*\cl.exe seems to be a workaround, but it quadruples the runtime of vswhere (from ~1 second to ~4 seconds).

Full Output on my specific setup:

> & $vswhere -find **\cl.exe
C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\Git\usr\bin\getfacl.exe
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.36.32532\bin\Hostx64\arm\cl.exe
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.36.32532\bin\Hostx64\arm64\cl.exe
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.36.32532\bin\Hostx64\x64\cl.exe
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.36.32532\bin\Hostx64\x86\cl.exe
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.36.32532\bin\Hostx86\arm\cl.exe
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.36.32532\bin\Hostx86\arm64\cl.exe
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.36.32532\bin\Hostx86\x64\cl.exe
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.36.32532\bin\Hostx86\x86\cl.exe

> & $vswhere -find **\*\cl.exe
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.36.32532\bin\Hostx64\arm\cl.exe
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.36.32532\bin\Hostx64\arm64\cl.exe
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.36.32532\bin\Hostx64\x64\cl.exe
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.36.32532\bin\Hostx64\x86\cl.exe
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.36.32532\bin\Hostx86\arm\cl.exe
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.36.32532\bin\Hostx86\arm64\cl.exe
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.36.32532\bin\Hostx86\x64\cl.exe
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.36.32532\bin\Hostx86\x86\cl.exe

$vswhere holds the full path as string to vswhere.exe as part of the VS Installer.

I found this issue first with the vswhere.exe shipped with Visual Studio Installer (3.1.1) and tested again with the latest version available in this repository (3.1.4). Both are affected.

[heaths]

@matcav @tydunkel this may not be a straight-forward fix. The current glob implementation uses C++ regex and builds a pattern that has a trailing, optional backslash so that it can match files in the root (which globstars are supposed to). We can't make that backslash required without breaking existing, common patterns. Also, C++ 11 regex uses ECMA-262 grammar (though this implementation doesn't use the full ECMAScript version because it doesn't need it) so grammar is limited. For example, lookahead assertions are supported, but not lookbehind (which is what I think is needed here). A full glob implementation may actually be necessary.