`switch -File` unexpectedly and invariably interprets the path as a wildcard expression

[mklement0]

Related: #4726

Steps to reproduce

New-Item 'foo[0].txt'
switch -File 'foo[0].txt' { default { 'hi' } }

Expected behavior

No output (the file is empty, there's nothing for switch -File to iterate over).

Actual behavior

The following error occurs:

No files matching 'foo[0].txt' were found.

That is, filename foo[0].txt was interpreted as a wildcard pattern, not a literal name.

With the current behavior, the workaround is to `-escape the [ and ] chars.

Note that even successfully resolving the wildcard expression ultimately fails if it resolves to multiple filenames, so the utility of interpretation-as-wildcard is questionable.

Environment data

PowerShell Core v6.2.0-preview.4 on macOS 10.14.2
PowerShell Core v6.2.0-preview.4 on Ubuntu 18.04.1 LTS
PowerShell Core v6.2.0-preview.4 on Microsoft Windows 10 Pro (64-bit; Version 1803, OS Build: 17134.471)
Windows PowerShell v5.1.17134.407 on Microsoft Windows 10 Pro (64-bit; Version 1803, OS Build: 17134.471)

[iSazonov]

Do you mean that we should interpret the path as Literal? It is not a breaking change and I like it.

@rjmholt It could be good issue for hackathon if you still continue.

[mklement0]

@iSazonov: Yes, as in the case of #4726 I think the path should always have been interpreted as a literal path.

Do note, however, that it is technically a breaking change, because someone could rely on code such as the following:

# Note: Only works if exactly ONE *.txt file exists in the current dir.
switch -file *.txt { 'hi' { 'there' } }

That said, I think it's a Bucket 3: Unlikely Grey Area change.

[iSazonov]

@SteveL-MSFT Could PowerShell Committee approve the breaking change?

[IISResetMe]

Wouldn't it be better to just clarify this in the documentation? It's easily solved:

$file = [WildcardPattern]::Escape('foo[0].txt')
switch -file $file { 'abc' { 'something something' } }

[vexx32]

I mean, given the fact that having a wildcard that resolves to multiple files fails with no reason I think that it would make more sense to be a literal path.

The alternative would be to fix the wildcard interpretation by a) allowing it to actually work with wildcards that resolve to multiple files, and b) add a -LiteralFile switch instead to allow ease of use with literal paths.

Both should probably accept an array of values, too.

[iSazonov]

I'd consider the Issue as UX issue. Any complications worsen UX. So allowing wildcards implicitly convert switch to cycle that is likely to worsen UX.

[mklement0]

If we stick with the current single-input-file-only behavior:

• The always-as-wildcard interpretation is so useless and unexpected (as it is in the invocation scenarios in Some scripts / files with wildcard metacharacter [ in the file name or path cannot be invoked or redirected to #4726) that the only reason to stick with it would be the fear of breaking existing code.

• Since I think it's pretty unlikely someone relied on the old behavior (why would you use a wildcard that you know must resolve to a single file and not just target that single file directly? if you don't know, use Get-Item / Convert-Path / Resolve-Path), the behavior should be fixed.

---

Allowing multiple input files is intriguing, but I think it would requires additional functionality to be useful:

• Access to information about the file currently being processed.

• Possibly also allow actions to be taken before and after a given file has been processed, along the lines of GNU awk's BEGINFILE / ENDFILE patterns.

While switch -File currently languishes in obscurity, perhaps adding such functionality could make it a more widely used tool; it certainly provides great performance benefits.

Even then it's possible to stay away from wildcards, however, so as to avoid the whole -Path / -LiteralPath (-File, -LiteralFile) mess; with array support, you could then write:

switch -File (Get-Item *.txt) { ...

[iSazonov]

Looks like duplication of Select-String.