Vista - Backticks added to file names containing square brackets

I'm running PowerShell (v1.0) on Windows XP Professional (SP2, EN-US), and
have found that tab completion doesn't work for file names containing square
brackets:

Create a file called "[a_file].txt" in Explorer (I can't figure out how to
create the file in PowerShell).

Try to list the file in PowerShell, first by typing "*a_file*.txt", then by
typing the same thing, plus Tab to complete the file name:

>>
PS C:\> ls *a_file*.txt
...
----- 12/02/2007 20:00 0 [a_file].txt

PS C:\> ls '`[a_file`].txt'
Get-ChildItem : Cannot find path 'C:\`[a_file`].txt' because it does not
exist.
At line:1 char:3
+ ls <<<< '`[a_file`].txt'
PS C:\>
<<

Curiously, the same string, "'`[a_file`].txt'", works to remove the file:

>>
PS C:\> rm '`[a_file`].txt'
PS C:\> ls *a_file*
PS C:\>
<<

However, if this string is used to create a file via output redirection, the
resulting file name contains backticks, i.e. is called "`[a_file`].txt",
rather than "[a_file].txt" (and naturally without the backticks, the file
name is invalid, so no file is created):

>>
PS C:\> echo data >'`[a_file`].txt'
PS C:\> ls *a_file*
...
----- 12/02/2007 20:14 14 `[a_file`].txt
<<

When trying to remove this file (with the name generated by tab completion),
PowerShell doesn't report an error, but doesn't remove the file either:

>>
PS C:\> rm '``[a_file``].txt'
PS C:\> ls *a_file*
...
----- 12/02/2007 20:14 14 `[a_file`].txt
<<

Using "*a_file*" as the argument to "Remove-Item" allows the file to be
removed.

A related problem is that, when launching applications (e.g. Notepad) from
PowerShell, backticks are added before square brackets in file names, with
the result that the files can't be found by the application.

Overall, there appears to be a bug in which backticks are only processed as
escape characters sometimes. Is this a known bug?

-Thomas

Hi Thomas;

This is a complex area in PowerShell.

- Some characters mean special things to the PowerShell scripting
language, such as the back-tick.
- Some characters mean special things to cmdlets that accept filenames,
such as * and square brackets.
- Both back-ticks and square brackets are legal filename characters.

We have two ways to support these scenarios:

- Putting a string in single quotes prevents characters from carrying
their special meaning in the scripting language.
- Using the -Literal___ parameters (such as -LiteralPath) prevents
characters from carrying their special meaning in cmdlets that support that
parameter.

More comments inline.

"Thomas" <tas at mailueberfall.de> wrote in message
news:%23QeYzytTHHA.5016@TK2MSFTNGP05.phx.gbl...
> I'm running PowerShell (v1.0) on Windows XP Professional (SP2, EN-US), and
> have found that tab completion doesn't work for file names containing
> square brackets:
>
> Create a file called "[a_file].txt" in Explorer (I can't figure out how to
> create the file in PowerShell).

New-Item -Type file [a_file].txt


>
> Try to list the file in PowerShell, first by typing "*a_file*.txt", then
> by typing the same thing, plus Tab to complete the file name:
>
>>>
> PS C:\> ls *a_file*.txt
> ...
> ----- 12/02/2007 20:00 0 [a_file].txt
>
> PS C:\> ls '`[a_file`].txt'
> Get-ChildItem : Cannot find path 'C:\`[a_file`].txt' because it does not
> exist.
> At line:1 char:3
> + ls <<<< '`[a_file`].txt'
> PS C:\>

dir -LiteralPath "[a_file].txt".

> Curiously, the same string, "'`[a_file`].txt'", works to remove the file:
>
>>>
> PS C:\> rm '`[a_file`].txt'
> PS C:\> ls *a_file*
> PS C:\>

This is also the direct way to do it:

Remove-Item -LiteralPath [a_file].txt

> However, if this string is used to create a file via output redirection,
> the resulting file name contains backticks, i.e. is called
> "`[a_file`].txt", rather than "[a_file].txt" (and naturally without the
> backticks, the file name is invalid, so no file is created):
>
>>>
> PS C:\> echo data >'`[a_file`].txt'
> PS C:\> ls *a_file*
> ...
> ----- 12/02/2007 20:14 14 `[a_file`].txt
> <<

The cmdlet that lets you create a file does not support wildcards, so it
treats all names as literal.

>
> When trying to remove this file (with the name generated by tab
> completion), PowerShell doesn't report an error, but doesn't remove the
> file either:
>
>>>
> PS C:\> rm '``[a_file``].txt'
> PS C:\> ls *a_file*
> ...
> ----- 12/02/2007 20:14 14 `[a_file`].txt
> <<

This is a bug. Could you please file it on MS Connect?

> Using "*a_file*" as the argument to "Remove-Item" allows the file to be
> removed.
>
> A related problem is that, when launching applications (e.g. Notepad) from
> PowerShell, backticks are added before square brackets in file names, with
> the result that the files can't be found by the application.

Notepad doesn't support wildcard expansion, so you can just use the name
like normal:

notepad [a_file].txt


> Overall, there appears to be a bug in which backticks are only processed
> as escape characters sometimes. Is this a known bug?

It is unfortunately complex, but we hope that the LiteralPath and
non-expanding (single-quoted) strings help in that regard.

--
Lee Holmes [MSFT]
Windows PowerShell Development
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.