If you’ve been using PowerShell for long, you are probably familiar with the concept of wildcards. At the very least, you’ve done something like this:
PS C:\temp> dir *.txt Directory: C:\temp Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 1/21/2015 10:01 AM 664 test.txt
Or perhaps you’ve taken a lap or two around about_wildcards and now type things like this in your sleep:
PS C:\temp> dir C:\win*\*.N[a-f]?\F*\v2*\csc.exe Directory: C:\Windows\Microsoft.NET\Framework\v2.0.50727 Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 5/26/2014 9:39 PM 77960 csc.exe Directory: C:\Windows\Microsoft.NET\Framework64\v2.0.50727 Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 5/26/2014 9:39 PM 88712 csc.exe
While wildcarding in the Path parameter is both powerful and useful, you might have seen another parameter: Filter.
In the PowerShell documentation, we describe the –Filter parameter in Get-ChildItem as:
Specifies a filter in the provider’s format or language. The value of this parameter qualifies the Path parameter. The syntax of the filter, including the use of wildcards, depends on the provider. Filters are more efficient than other parameters, because the provider applies them when retrieving the objects, rather than having Windows PowerShell filter the objects after they are retrieved.
In a SQL provider, the –Filter parameter might offer SQL syntax (like: –Filter “WHERE Name LIKE %pattern%”). Or, the AD provider might offer LDAP syntax. In the FileSystem provider, PowerShell’s wildcard syntax (dir *.txt) is very similar to the NTFS “format or language” which also looks like: *.txt. In the Filesystem Provider’s case, the Win32 API (FindFirstFile) takes a pattern parameter that is then processed by the API itself.
When you use wildcards in cmd.exe, file resolution and wildcarding is done directly by this Win32 API.
What’s the difference?
Now you might wonder about Filesystem: if both wildcards and filters are so similar, why does PowerShell need its own? Why not just call the Win32 API like cmd.exe does?
The primary distinction is around power. As about_wildcards mentions, PowerShell offers the character and character range operators. The native Win32 API does not.
Wildcard Description Example Match No match
——– —————— ——– —————– ——–
* Matches zero or a* A, ag, Apple banana
? Matches exactly ?n an, in, on ran
one character in
[ ] Matches a range [a-l]ook book, cook, look took
[ ] Matches specified [bc]ook book, cook hook
There’s also a surprising distinction around correctness. Try these examples in your System32 directory.
Should return all files with three-letter extensions:
$r1 = dir *.???
$r2 = dir –Filter *.???
Compare-Object $r1 $r2 –Property FullName
(Oops! –Filter returns directories, as well as files with 1 or 2 letter extensions!)
Should return all files with “2” in the name
$r1 = dir *2*
$r2 = dir –Filter *2*
Compare-Object $r1 $r2 –Property FullName
(Oops! –Filter returns a ton of stuff without “2” in the name.)
For the last example, this is because native wildcard filters ALSO work against the 8.3 filename representation!
PS C:\windows\system32> cmd /c dir /x *2* | sls SqlServerSpatial.dll 04/03/2010 10:57 AM 459,104 SQLSER~2.DLL SqlServerSpatial.dll
But what about performance?
Native Filesystem filters are unquestionably faster than PowerShell doing all of the wildcard matching on its own. However, PowerShell doesn’t do all of the matching on its own. In Version 2, we added support for partial filtering to the Filesystem provider (and of course, to any other provider that wants to implement it). When the Filesystem provider applies this partial filtering, it offloads as much of the filtering work as it can to the raw Win32 APIs – and then does more powerful (and correct) wildcard matching on the smaller set of results.
So now you know – when it comes to the Filesystem provider, you probably don’t want or need the –Filter parameter!
If you want to know more about wildcarding in the Filesystem provider, this is covered in Recipe 20.6 in the PowerShell Cookbook, which you can preview for free here: Find Files that Match a Pattern.