Forum Discussion

Michael_Brooks's avatar
Michael_Brooks
Copper Contributor
May 02, 2024

Asterisk (*) wildcard at end of string not matching file

OK, I must be missing something obvious here. I perform a search for files with the string "oslo" in the name, via:

 

Get-ChildItem *oslo* -file -recurse

 

This produces no results. I drop the second asterisk. i.e.:

 

Get-ChildItem *oslo -file -recurse

 

This results in files with a ".oslo" extension.

To my understanding, "*" is supposed to match zero or more characters. On that basis, both the above searches should have resulted in files with a ".oslo" extension.

Incidentally, I get the same behaviour regardless of whether I surround my search string with double-quotes.

What am I missing?

Cmdlets

7 Replies

Sort By
  • Michael_Brooks's avatar
    Michael_Brooks
    Copper Contributor
    May 07, 2024
    I posted this 5 days ago and so far no one has been able to suggest anything that I might be doing wrong. Am I to suspect that this is a bug in Microsoft's code? I find that possibility hard to swallow, not because Microsoft never ship buggy code but because it's a bit too fundamental to have slipped through the testing net - the difference between a wildcard matching zero or more characters and matching one or more characters is so significant as to warrant separate characters when performing regular expression parsing (not that we're parsing regular expressions here - I'm merely highlighting how significant this nuance is). Perhaps I've made assumptions as to the syntax of this wildcard when used in the -Name parameter (it's not explicitly spelled out in the documentation, although the explanation for wildcards in the -Filter parameter does differentiate between * and ?)?
    • LainRobertson's avatar
      LainRobertson
      Silver Contributor
      May 08, 2024

      Michael_Brooks 

       

      Hi, Michael.

       

      I can't reproduce the issue you're seeing in either Windows PowerShell or PowerShell, but I can at least confirm your understanding of the asterisk wildcard is correct insofar as it means "zero or more characters".

       

      As you've noted, it's not actually a regular expression being used here but a pattern matching implementation contained within the file system API itself, which is why the pattern matching is the same in PowerShell as the "dir" command from the command prompt (i.e. DOS command window). For this reason, it's hard to comprehend why you're seeing what you're seeing.

       

      For posterity, I ran the following tests with identical results across all three:

       

      Get-ChildItem -File -Filter "*xlsx*";
Get-ChildItem -File -Filter "*xlsx";
Get-ChildItem -File -Filter "*xl*sx*";

       

      It won't provide any resolution, but it would be interesting to try the same patterns in a DOS "dir" command (example below) to see if you get the same result as in PowerShell (i.e. if the issue is PowerShell specific or something with wider reach).

       

       

      Without being able to reproduce the issue, there's nothing I can really offer.

       

      Cheers,

      Lain

      • Michael_Brooks's avatar
        Michael_Brooks
        Copper Contributor
        May 08, 2024

        Thanks LainRobertson . I notice that you used the wildcards in the -Filter option, whereas mine were being used in the -Name option (by default, since I hadn't specified an option prior to the string). Experimenting, I see that I am getting different results depending upon whether I use the -Filter option and also whether I am searching in just the current directory (as you are) or recursing through a hierarchy.


        So 

         

        gci *oslo* -File

         

        and

         

        gci *oslo* -File -Recurse

         

        work when files ending ".oslo" exist in the current working directory, and

         

         gci -File -Recurse -Filter *oslo*

         

        works when the files exist in subdirectories, but

         

        gci *oslo* -File -Recurse

         

        does not work when the files exist in subdirectories.

        This is more subtle than I initially appreciated, and consequently I am now beginning to wonder whether I have stumbled across a bug after all.

        For the record, I appear to be getting consistent behaviour between Windows PowerShell and PowerShell.

         

        Regards,

        Michael

Resources