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 ...
Cmdlets
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

      • LainRobertson's avatar
        LainRobertson
        Silver Contributor
        May 08, 2024

        Michael_Brooks 

         

        It wouldn't be using the -Name parameter by default since that's a switch. My best guess is it would be applied to -Path, based on the defined parameter sets and position within those sets.

         

         

        Setting that aside (given we're only interested in the outcome), when I use "*pattern*" with "-File -Recurse", I get the same results as explicitly using -Filter, so I don't have anything to offer up.

         

        Cheers,

        Lain

Resources