Some scripts / files with wildcard metacharacter [ in the file name or path cannot be invoked or redirected to

[mklement0]

^{Edited for the current status as of PowerShell Core 7.3.0-preview.4}

Note:

• Originally, this issue was also about the inability to execute files whose literal names happen to be syntactically invalid wildcard patterns.

• This execution aspect was partially fixed in Make command searcher not use wildcard search for execution #9202 (but wasn't back-ported to the currently stable version, v6.2.3)

  • Invocation by wildcard pattern still works as a fallback, but paths with [ and ] that exist literally now take precedence.
  • Therefore, if no literal match is present, you may still end up invoking an unrelated file by accident, which is problematic (e.g., if a.ps1 is present in the current dir. and .\[ab].ps1 is invoked, with no file literally named [ab].ps1 present, .\a.ps1 is executed instead.)

Seemingly, all external-executable invocation methods ( ., &, Start-Process, powershell -File) as well as redirections > / >> mistakenly interpret script / file paths as wildcard patterns, and if a path that contains [ happens not contain a syntactically valid range expression, invocation and redirection break (in Windows PowerShell, no longer in PowerShell Core, except with Start-Process) or can end up accidentally targeting an unrelated executable.

• In other words: The problem sometimes occurs, unless each instance of [ happens to be part of a valid range expression; e.g., a[b] (valid) vs. a[b (invalid); curiously, however, the equally invalid b[b does not.

• But even with a syntactically valid range expression - and some invalid ones - the behavior is unexpected:

  • 'foo' > 'file[1].txt' attempts wildcard matching and complains, Cannot perform operation because the wildcard path file[1].txt did not resolve to a file.
    • Attempting escaping then inappropriately retains the escape characters - see Passing an escaped wildcard expression to -Path in file-creating cmdlets causes the escaped representation to be used as the literal filename #9475

• Attempting to invoke (open) such a file fails quietly, even with escaping (run New-Item file[1].txt first):

  • ./file[1].txt ... quiet no-op
  • ./file`[1`].txt ... quiet no-op
  • If you created a .ps1 file named, say, file[1].ps1 ('"hi"' | Set-Content -LiteralPath file[1].ps1):
    • Invocation with an explicit path unexpectedly only works if .ps1 is also specified.
    • Invocation via $env:PATH doesn't work at all - neither with or without .ps1

Fundamentally, external-executable / redirection output paths should be treated as literals in these situations.
See this comment for a discussion and an overview of related issues.

Original tests below.

Steps to reproduce

Run the following Pester tests.

Describe "Redirection with and invocation of literal file paths that are invalid as wildcard patterns" {

  BeforeAll {
    Push-Location testdrive:\
    $f1 = './t[1.ps1'
    $f2 = './t[1.txt'
    New-Item -Type File $f1 -Value "'hi'"
  }

 # Passes now, due to fix in #9202
  It "Script file can be dot-sourced." {
    . $f1 | Should -Be 'hi'
  }

 # Passes now, due to fix in #9202
  It "Script file can be called." {
    & $f1 | Should -Be 'hi'
  }

 # Passes now, due to fix in #9202
  It "Script file can be called via CLI with -File" {
    pwsh -noprofile -file $f1 | Should -Be 'hi'
  }

  It "Redirection works with new file (>)" {
    & { 'hi' > $f2; Get-Content -LiteralPath $f2 } | Should -Be 'hi'
  }

  It "Redirection works with existing file (>)" {
    New-Item -Force -Type File $f2
    & { 'hi' > $f2; Get-Content -LiteralPath $f2 } | Should -Be 'hi'
  }

  It "File path is passed correctly to external programs" {
    if ($IsWindows) {
      cmd /c type ($f1 -replace '/', '\') | Should -Be "'hi'"
    } else {
      /bin/cat $f1 | Should -Be "'hi'"
    }
  }

  AfterAll {
    Pop-Location
  }
}

Expected behavior

All tests should pass.

Actual behavior

The > tests fail on all platforms.

In v6.2.3, the invocation tests fail too.

Environment data

PowerShell Core 7.0.0-preview.5

Originally reported for PowerShell Core v6.0.0-beta.7.

[iSazonov]

It seems we should escape (try tab completion):

. './t`[`].ps1'

[mklement0]

No, I think there is no reason to attempt wildcard pattern matching at all in all these scenarios - the paths should be taken as literals, which obviates the need for escaping.

[iSazonov]

I discover this in #4699 and we can see this in https://github.com/iSazonov/PowerShell/blob/c1b300caeef8e242e484eb827667931fde714796/test/powershell/Host/TabCompletion/TabCompletion.Tests.ps1#L752

[mklement0]

When tab-completing for parameters that support wildcards, the escaping you mention makes sense:

# -Path implied, which supports wildcards -> escaping
Get-Item './t`[`].ps1'  # The result of typing Get-Item ./t<tab> *on Unix*

# -LiteralPath specified, which does NOT support wildcards -> NO escaping
Get-Item -LiteralPath ./t[].ps1  # The result of typing Get-Item -LiteralPath ./t<tab>

Since there is no good reason to treat the file path in scenarios such as . <file-path> as a wildcard pattern:

• tab completion should work the same way it does with Get-Item -LiteralPath - treat it as a literal.

• and execution of such a path should obviously succeed.

[iSazonov]

Here can be a root of the bug.

[daxian-dbw]

@mklement0 The file redirection is broken for this scenario, but the invocations seem working fine on beta.7:

PS:4> '"Hi!"' | Set-Content -literalpath './t[].ps1'
[F:\tmp]
PS:5> ./t[].ps1
Hi!
[F:\tmp]
PS:6> . './t[].ps1'
Hi!
[F:\tmp]
PS:7> & './t[].ps1'
Hi!
[F:\tmp]
PS:8> E:\pscore\powershell.exe -noprofile -file './t[].ps1'
Hi!
[F:\tmp]
PS:9>

The $PSVersion:

PS:9> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      6.0.0-beta
PSEdition                      Core
GitCommitId                    v6.0.0-beta.7
OS                             Microsoft Windows 10.0.15063
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Am I missing something?

[mklement0]

@daxian-dbw:

Sorry, I didn't realize that the behavior varies with similar filenames present in the same directory.

I've updated the original post with scenarios that should fail predictably with initially empty directories, on both Windows and Unix platforms.

The key is to use something like t[.ps1 - something truly invalid if interpreted as a wildcard pattern.

[daxian-dbw]

@mklement0 Thanks for the clarification!