> > The future is powershell, where this command only matches in the
> name part
> > Get-ChildItem *sh*.*
> >
>
> I tested that, as follows:
> powershell -command Get-ChildItem *sh*.*
>
> This works fine, but does not seem to find matching files with no
> extension. Am I missing something?
Different applications handle wildcards differently, so you have to learn the rules for each. It appears that PowerShell handles a trailing .* as must have an extension or at least must have a "." (sort of, the same thing).
Under cmd "*sh*." and "*sh*" are the same, under powershell they are not.
>
> Thus, it seems to me that this powershell alternative is more or less
> equaivalent to the dir alternative:
> dir "*sh*. ^.[^.]*$"
I cannot get that to work in powershell or cmd.
> But then you will only get the filenames listed. Similar regexp
> functionality is of course also available under powershell.
This might be a better way to handle the requirement in powershell, as it lets you match against the parts of the directory entries
Get-ChildItem C:\Windows\*.* | Where-Object { $_.Basename -like '*sh*'}
You can also combine filters like this
Get-ChildItem C:\Windows\*.* | Where-Object { $_.Basename -match 'sh' -and $_.length -gt 0}
Note:
-like uses wildcards
-match uses regular expressions
Undocumented CMD.exe Wildcards
I didn't know about those, so I did some searching and found https://ss64.com/nt/syntax-wildcards.html
Testing a few options, this will return files with sh in the base name, and will match files with and without extensions.
dir /a-d "
Reading the link above some warnings
1. cmd matches against the short and longnames, so this will match all files with shortnames, or ~ in the basename.
dir /a-d "<~<.*"
2. Only commands internal to cmd use the Undocumented Wildcards
That's makes using Powershell an advantage, as the filters will be all using the same wildcard rules, or the one RE engine if you use the "Where-Object { $_.field -match 'sh' }" form.
Ben