When you include something like
 in a file name like
File.txt used with the
Invoke-WebRequest and the
-OutFile parameter you get an error
Cannot perform operation because the wildcard path File.txt did not resolve to a file.
This is caused by the behavior documented here.
With other cmdlets you would use
-LiteralPath to force the path to be taken literally but in this case that is not an option.
I have tried escaping the
] characters with
\ but it still gives the same error.
To simplify testing you can reproduce the same issue with
Out-File -FilePath "file.txt"
Out-File -FilePath "file`[1`].txt"
Out-File -FilePath "file\[1\].txt"
Out-File -LiteralPath "file.txt"
Test-Path -Path "file.txt"
Test-Path -LiteralPath "file.txt"
How can I escape characters that would be used to express wildcards in
-OutFile, etc. so that they function like the string was specified with
-LiteralPath isn't available with
- In PowerShell (Core) 7.1+, file paths passed to the
Invoke-RestMethodare now interpreted literally:
- That is,
-OutFilenow acts like
-LiteralPath, and there is no longer a need to escape
]characters, so that the following example command works as-is:
Default123# PowerShell 7.1+ only.Invoke-WebRequest http://example.org -OutFile File.txt
- That is,
- Therefore, the following applies only to Windows PowerShell (and to now-obsolete PowerShell (Core) versions v7.0 and below):
] characters as
] so that they are treated literally when interpreted as a wildcard expression with
-OutFile unfortunately only half works at the moment, due to a bug discussed in the bottom section:
- Performing the escaping ensures that the target parameter accepts the path (the command doesn't break anymore) ...
- ... but on creation of the file it is mistakenly the escaped representation that is used as the literal filename - see bottom section.
Workaround for now:Tip of the hat to hashbrown for helping to simplify it.
Invoke-WebRequestsave to a temporary file...
- ... and then rename (move) the temporary file to the desired output file path.
# Literal output file path.
$outFile = '.\file.txt'
# Simulate a call to Invoke-RestMethod / Invoke-WebRequest -OutFile.
# Save to a *temporary file*, created on demand - such
# a temporary file path can be assumed to never contain '[' or ']'
'hi' | Out-File -FilePath ($tempFile = New-TemporaryFile)
# Rename (move) the temporary file to the desired target path.
Move-Item -Force -LiteralPath $tempFile -Destination $outFile
In Windows PowerShell v4-, use
[IO.Path]::GetTempfileName() in lieu of
Escaping [literal] paths for use as wildcard patterns:
Use any of the following string-literal representations, which ultimately result in the same string with verbatim content
].txt, which, when interpreted as a wildcard expression, is the escaped equivalent of literal string
To create this escaping programmatically, use:
$literalName = 'file.txt'
$escapedName = [WildcardPattern]::Escape($literalName) # -> 'file`[1`].txt'
What matters is that the target cmdlet sees the
-escaped in the
-FilePath) argument it is passed for them to be treated verbatim.
If you use
"..." quoting or an unquoted argument (which mostly behaves as if it were enclosed in
"..."), PowerShell’s string parsing gets in the way:
through, you must escape it itself, as
is also used as the escape character inside expandable strings (
"..."), so in order to pass
- Otherwise something like
is “eaten” – because
"..."turns into just
[is an escaped
"..."'s perspective, and escaping a character that doesn't need escaping turns into just that character; in short: both
].txtturn into plain
file.txt, as if you had never used
characters are used verbatim inside
'...'-quoted strings and need no escaping.
Flawed file-creation behavior of many cmdlets with
The bug mentioned above - that on file creation the escaped representation is mistakenly used as the literal filename - affects most cmdlets, unfortunately: That is, they unexpectedly retain the
characters in the escaped pattern on creating a file, so that by specifying
].txt' you’ll end up with a file literally named
Fortunately, most cmdlets do support
-LiteralPath, so use of
-LiteralPath file.txt is the better choice anyway and avoids this bug.
Some of the affected cmdlets:
Out-Fileand therefore also redirection operators
>>, which effectively call
Out-Filebehind the scenes.
- Note that
Add-Contentdo not exhibit this problem.
The bug has been reported in GitHub issue #9475.
 This was technically a breaking change, but it was considered acceptable, due to the counterintuitive nature of the original behavior. Unfortunately, the counterintuitive behavior still surfaces in many other contexts – including still with
-LiteralPath is explicitly used. See GitHub issue #17106 for a summary.