Get-Item -Filter parameter and wildcard MS-DOS based parsing

Hi,

Im trying to understand why in FileSystem provider -Filter parameter differently process wildcards compared to Include/Exclude parameters available in same provider?

Im working on example for school, and found out that if I use Get-Item with same wildcard patterns, I get different results based on parameter that I use. I read post how wildcards worked in MS-DOS and that is behavior I see when I use Filter parameter. I have tested on this on both PS 7.1 and 5.1 and it seems that there is also difference inside -Filter processing based on shell version (line 14 in code). For anyone interested here is my example code to follow, along with my interpretation of given results.

Set-Location c:\
New-Item -Path . -ItemType Directory -Name Folder
New-Item -Path .\Folder -ItemType File -Name note.txt 
New-Item -Path .\Folder -ItemType File -Name doc.docx
New-Item -Path .\Folder -ItemType File -Name something
New-Item -Path .\Folder -ItemType File -Name .net        
New-Item -Path .\Folder -ItemType File -Name .dot.file   
Set-Location -LiteralPath C:\Folder

<# ANOMMALIES WITH -FILTER PARAMETER AND 11 CHARACTER (8.3) PATTERN MATCHING ALGORITHM
 Source Link :https://devblogs.microsoft.com/oldnewthing/?p=24143 #>

get-item -Path * -Filter * #returns all matches (* match all files)
get-item -Path * -Filter *. #returns files with no extensions, (also matches .net file since it is aslo considered extensionless, but only in 5.1)
Get-Item -Path * -Filter *.???? #returns all files since *.???? equals *???? or *.* or *
Get-Item -Path * -Filter .* #fills file name (first 8 chars to space), position cursor on extension place (last 3 chars), match anything in extension 
Get-Item -Path * -Filter *.d* #work as expected since filter have 2 specific character that must match
Get-Item -Path * -Filter ???.* #first 3 ? wildcards could be zeroes since they come right before dot, so the pattern is based on specific dot character at position 4, or position 1

get-item -Path * -Include * #works same as in filter
get-item -Path * -Include *. #does return nothing because there in no file that can end with visible dot (see line 5)
Get-Item -Path * -Include *.???? #here pattern matching work as expected since include is not based on MS-DOS 8.3 file pattern
Get-Item -Path * -Include *.d* #this also works as expected
Get-Item -Path * -Include .* #this works correctly (search filenames insted of extensions) since there is a file that starts with dot in its name
Get-Item -Path * -Include ???.* # return doc.docx because we have first 4 character match

cd.. ; Remove-Item -LiteralPath 'C:\Folder\' -Recurse

Thanks

Did you read the documentation? Get-Help Get-Item

-Filter <System.String>
Specifies a filter to qualify the Path parameter. The FileSystem (…/Microsoft.PowerShell.Core/About/about_FileSystem_Provider.md)provider is the only installed PowerShell provider that supports filters. Filters are more efficient than other parameters. The provider applies filter when the cmdlet gets the objects rather than having PowerShell filter the objects after they’re retrieved. The filter string is passed to the .NET API to enumerate files. The API only supports * and ? wildcards.

-Include <System.String[]>
Specifies, as a string array, an item or items that this cmdlet includes in the operation. The value of this parameter qualifies the Path parameter. Enter a path element or pattern, such as .txt. Wildcard characters are permitted. The Include * parameter is effective only when the command includes the contents of an item, such as C:\Windows*, where the wildcard character specifies the contents of the C:\Windows directory.

-Filter parameter is handled by the .NET API and -Include is a PowerShell filter, so there are differences.

Thanks Mike for clarification,

It seems so easy now, but at the time of reading get-item help, I didn’t realize that difference. I presumed that all parameters from filesystem provider use same filter mechanic for dealing with wildcards, and was more focused on experimenting with examples than to again carefully read documentation.

Thank you again!