Copy file with square brackets [ ] in the filename and use * wildcard

The way that Powershell automatically tab-completes the filename is usually the best way,

Example:

copy-item '.\file`[test`].txt'

In this situation, you have to use double-backticks with single quotes in order to escape the brackets. You can also use quadruple backticks when you use double quoted strings.

So the fixed line of code is:

Copy-item -Path $FSG\$SW\0.RoomView.Notes\starter\'``[RoomView``] Versions explained*.pdf' -Destination $FSG\$containerFolder\$rootFolder\'Fusion Server'\

Another good resource on file paths and wired characters etc. is to read this article: Taking Things (Like File Paths) Literally


EDIT

Thanks to @mklement0 for highlighting that the true cause of this inconsistency is because of a bug currently in PowerShell1. This bug causes escaping of wildcard characters, as well as backticks with the default -Path parameter to behave differently than other parameters e.g. the -Include and -Filter parameters.

To expand on @mklement0's excellent answer, and comments, and other answers below:

To better understand why we need single quotes and two back ticks in this situation; (and to highlight the bug and inconsistencies) let's run through some examples to demonstrate what is going on:

Get-Item, and associated cmdlets (Get-ChildItem, Copy-Item, etc.), handle the -Path parameter differently when dealing with a combination of escaped wildcard characters and unescaped wildcard characters *at the same time***!

TLDR: The underlying reason that we need a combination of single quotes and double backticks is how the underlying PowerShell provider parses the -Path parameter string for wildcards. It appears to parse it once for the escape characters, and a second time for the evaluation of the wildcard.

Let's go through some examples to demonstrate this odd outcome:

First, let's create two files to test with called File[1]a.txt and File[1]b.txt

"MyFile" | Set-Content '.\File`[1`]a.txt'
"MyFriend" | Set-Content '.\File`[1`]b.txt'

We'll try different ways to get the file. We know that Square brackets [ ] are wildcards, and so we need to escaped them with the backtick character.

We will try to get one file explicitly.

Let's start by using single quoted literal strings:

PS C:\> Get-Item 'File[1]a.txt'
PS C:\> Get-Item 'File`[1`]a.txt'

    Directory: C:\

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       2019-09-06   5:42 PM              8 File[1]a.txt

PS C:\> Get-Item 'File``[1``]a.txt'

    Directory: C:\

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       2019-09-06   5:42 PM              8 File[1]a.txt

For single quoted strings, one backtick is all that is required to retrieve the file, but two backticks also work.

Using Double quoted strings we get:

PS C:\> Get-Item "File[1]a.txt"
PS C:\> Get-Item "File`[1`]a.txt"
PS C:\> Get-Item "File``[1``]a.txt"

    Directory: C:\  

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       2019-09-06   5:42 PM              8 File[1]a.txt

For double quoted strings, as expected, we can see that we need two backticks to make it work.

Now, we want to retrieve both files and use a wildcard.

Let's start with single quotes:

PS C:\> Get-Item 'File[1]*.txt'
PS C:\> Get-Item 'File`[1`]*.txt'
PS C:\> Get-Item 'File``[1``]*.txt'

    Directory: C:\

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       2019-09-06   5:42 PM              8 File[1]a.txt
-a----       2019-09-06   5:49 PM             10 File[1]b.txt

With the single quotes, when we have a wildcard character, we need two sets of backticks. One to escape the bracket, and a second backtick to escape the backtick that we used to escape the bracket when the wildcard is evaluated.

Similarly for double quotes:

PS C:\> Get-Item "File[1]*.txt"
PS C:\> Get-Item "File`[1`]*.txt"
PS C:\> Get-Item "File``[1``]*.txt"
PS C:\> Get-Item "File```[1```]*.txt"
PS C:\> Get-Item "File````[1````]*.txt"

    Directory: C:\

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       2019-09-06   5:42 PM              8 File[1]a.txt
-a----       2019-09-06   5:49 PM             10 File[1]b.txt

With double quotes it's a little more verbose to evaluate with a wildcard. In this case, we need four sets of back ticks. For double quotes we need two backticks to escape the bracket, and another two backticks to escape the escape characters once it comes to evaluation of the star wildcard.


EDIT

As @mklement0 mentions, this behavior with the -Path parameter is inconsistent, and behaves differently than the -Include parameter, where only a single backtick is required to properly escape the brackets. This may be "fixed" in a later version of PowerShell.


1 As of Windows PowerShell v5.1 / PowerShell Core 6.2.0-preview.3


An overview and some background information:

  • In order to effectively escape a character that you want to be interpreted verbatim as part of a wildcard expression, it must be `-escaped as seen by the target cmdlet (its underlying PowerShell drive provider).

  • Ensuring that can get tricky, because ` (backtick) is also used as the escape character in double-quoted strings ("...") and unquoted command arguments (which for the most part behave like double-quoted strings).

Note: The scenario in the question doesn't allow use of -LiteralPath, but in cases where you know a path to be a concrete, literal path, use of the -LiteralPath (which can be shorted to -lp in PowerShell Core) is the best choice - see this answer.

When passing an argument to the wildcard-supporting -Path parameter of a PowerShell drive provider-related cmdlet (Get-ChildItem, Copy-Item, Get-Content, ...) and you want [ and ] to be treated verbatim rather than as a character set/range expression:

  • String-literal representations:

    • 'file`[1`].txt'

      • ` chars. are preserved as-is inside '...', so the target cmdlet sees them, as intended.
    • "file``[1``].txt"

      • ``, i.e. doubling is needed inside "..." in order to preserve a single ` in the resulting string (the first ` is the (double-quoted) string-internal escape character, and the second ` is the character it escapes, to be passed through).
    • file``[1``].txt

      • Ditto for unquoted command arguments, which (for the most part) act like "..."
    • Caveat: Due to a bug - see this GitHub issue - mixing (unescaped) ? or * with escaped [ and ] requires the latter to be doubly escaped (with ``, as seen by the target cmdlet / provider):

      • If you wanted to match literal filename file[1].txt with a wildcard pattern that matches [ and ] literally while also containing special character * (to match any run of characters), instead of the expected 'file`[1`]*', you'll have to use 'file``[1``]*' (sic); with a double-quoted or unescaped argument you then have to effectively use quadruple backticks: "file````[1````]*" / file````[1````]* - see this answer for more.

      • Note that direct use of wildcards with the -like operator is not affected:

        • 'a[b' -like 'a`[*' is - correctly - $true,
        • whereas 'a[b' -like 'a``[*' - rightfully - complains about an invalid pattern.
      • Similarly, parameters -Include and -Exclude are not affected.

      • -Filter plays by different rules to begin with: [...] as a construct isn't supported at all, and [ and ] chars. are always considered literals (again, see this answer).

  • To escape a path string programmatically, via a variable, use:

      $literalName = 'file[1].txt'
      $escapedName = [WildcardPattern]::Escape($literalName) # -> 'file`[1`].txt'
    


I use this:

 Copy-Item  $file.fullname.replace("[", "``[").replace("]", "``]") $DestDir