Steps to reproduce

Create an executable file with PowerShell wildcard characters in its name, say a[hello].ps1, place it somewhere in the PATH, and then try to execute it from PowerShell.

Describe "Execute scripts by file name only via `$env:PATH." {
  BeforeAll {
	$originalPath= $env:PATH
    $dir = Convert-Path TestDrive:
    "'hi1'" | Set-Content -LiteralPath $dir/script.ps1
    "'hi2'" | Set-Content -LiteralPath $dir/script[1].ps1
    $env:PATH += [IO.Path]::PathSeparator + $dir
  }
  AfterAll {
    $env:PATH = $originalPath
  }
  It "Finds and executes a script with a vanilla file name." {
    script.ps1 | Should -Be 'hi1'
  }
  It "Finds and executes a script whose file name looks like a wildcard." {
    script[1].ps1 | Should -Be 'hi2'
  }
}

Expected behavior

The file executes

Actual behavior

It doesn't, but is suggested as a possible similar command.

There is no escaping of the wildcard characters that works.

Environment data

All version of PowerShell, on Windows 10, specifically 5.1, 6.2.3, and 7.0.0-preview5 were tested.

Reason - Determined from Debug

Because the command contains wildcard characters, it is rejected from a PATH search by CommandSearcher.CanDoPathLookup() in CommandSearcher.setupPathSearcher(). If the command had been in the immediate path, using .\a[hello].ps1 would have successfully worked.

@mklement0, I believe you may have touched on this subject before, but I could not immediately find an existing issue for this.

I believe this can be corrected, by only sending an escaped version of the path to CommandSearcher.CanDoPathLookup(), as I cannot find any reason that the path should not be treated literal at this point. Or, maybe the wildcard character check can be removed entirely, it appears this is the only place where the function CanDoPathLookup() is used.