How PowerShell parses

For PowerShell to be successful as a shell, it can’t require that everything be quoted.

PowerShell would fail if it required people to continually type

cd ".."

or

copy "foo.txt" "bar.txt"

On the other hand, people have a strong idea of how expressions should work:

2

This is the number 2, not a string “2”. Consequently, PowerShell has some rather complicated parsing rules. The next three sections will cover these rules. We’ll discuss how quoting is handled, the two major parsing modes, and the special rules for new-lines and statement termination.

2.4.2 Quoting

Quoting is the mechanism used to turn a token that has special meaning to the Pow-erShell interpreter into a simple string value. For example, the Write-Output cmdlet has a parameter -InputObject. But what if you want to actually use the string

“-InputObject” as an argument, as mentioned earlier? To do this, you have to quote it;

that is, you surround it with single or double quotes. The result looks like this:

PS (2) > Write-Output '-InputObject' -inputobject

What would happen if you hadn’t put the argument in quotes? Let’s find out:

PS (3) > Write-Output -InputObject

Write-Output : Missing an argument for parameter 'InputObject'.

Specify a parameter of type 'System.Management.Automation.PSObject[]’and try again.

At line:1 char:25

+ Write-Output -inputobject <<<<

PS (4) >

As you can see, this produces an error message indicating that an argument to the parameter -InputObject is required.

PowerShell supports several forms of quoting, each with somewhat different meanings (or semantics). Putting single quotes around an entire sequence of charac-ters causes them to be treated like a single string. This is how you deal with file paths that have spaces in them. For example, if you want to change to a directory whose path contains spaces, you type this:

PS (4) > cd 'c:\program files'

PS (5) > pwd Path

----C:\Program Files

What happens if you don’t use the quotes?

PS (6) > cd c:\program files

Set-Location : A parameter cannot be found that matches paramete r name 'files'.

At line:1 char:3

+ cd <<<< c:\program files

When you don’t use the quotes, you receive an error complaining about an unex-pected parameter in the command because "c:\program" and "files" are treated as two separate tokens.

NOTE Notice that the error message reports the name of the cmdlet, not the alias that was used. This way you know what is being executed.

The position message shows you the text that was entered so you can see that an alias was used.

One problem with using matching quotes as we did in the previous examples is that you have to remember to start the token with an opening quote. This raises an issue when you want to quote a single character. You can use the backquote (`) character to do this (the backquote is usually the upper-leftmost key, below Esc):

PS (6) > cd c:\program` files PS (7) > pwd

Path

----C:\Program Files

The backquote, or backtick, as it tends to be called, has other uses that we’ll explore later in this section. Now let’s look at the other form of matching quote: double quotes. Once again, here’s our favorite example:

PS (8) > cd "c:\program files"

PS (9) > pwd Path

----C:\Program Files

It looks pretty much like the example with single quotes, so what’s the difference? In double quotes, variables are expanded. In other words, if the string contains a variable reference starting with a ^$, it will be replaced by the string representation of the value stored in the variable. Let’s look at an example. First assign the string “files” to the variable ^$v:

PS (10) > $v = "files"

PARSINGAND POWERSHELL 53 Now reference that variable in a string with double quotes:

PS (11) > cd "c:\program $v"

PS (12) > pwd Path

----C:\Program Files

The ^cd succeeded and the current directory was set as you expected. What happens if you try it with single quotes? Here you go:

PS (13) > cd 'c:\program $v'

set-location : Cannot find path 'C:\program $v' because it does not exist.

At line:1 char:3

+ cd <<<< 'c:\program $v' PS (14) >

Because expansion is performed only in double quotes and not in single quotes, you get an error because the unexpanded path doesn’t exist.

Take a look at another example:

PS (14) > '$v is $v'

$v is $v

PS (15) > "$v is $v"

files is files

In the single-quoted case, $v is never expanded; and in the double-quoted case, it’s always expanded. But what if you really want to show what the value of ^$v is? To do this, you need to have expansion in one place but not in the other. This is one of those other uses we had for the backtick. It can be used to quote or escape the dollar sign in a double-quoted string to suppress expansion. Let’s try it:

PS (16) > Write-Output "`$v is $v"

$v is files

Here’s one final tweak to this example—if ^$v contained spaces, you’d want to make clear what part of the output was the value. Because single quotes can contain double quotes and double quotes can contain single quotes, this is straightforward:

PS (17) > Write-Output "`$v is '$v'"

$v is 'files' PS (18) >

Now, suppose you want to display the value of $v on another line instead of in quotes. Here’s another situation where you can use the backtick as an escape ter. The sequence `n in a double-quoted string will be replaced by a newline charac-ter. You can write the example with the value of ^$v on a separate line as follows:

PS (19) > "The value of `$v is:`n$v"

The value of $v is:

Files

Table 2.1 lists the special characters that can be generated using backtick (also called escape) sequences.

Note that escape sequence processing, like variable expansion, is only done in double-quoted strings. In single-double-quoted strings, what you see is what you get. This is particu-larly important when writing a string to pass to a subsystem that does additional lev-els of quote processing.

If you’ve used another language such as C, C#, or Perl, you’ll be accustomed to using the backslash instead of the backtick for escaping characters. Because Power-Shell is a shell and has to deal with Windows’ historical use of the backslash as a path separator, it isn’t practical to use the backslash as the escape character. Too many applications expect backslash-separated paths, and that would require every path to be typed with the slashes doubled. Choosing a different escape character was a difficult decision that the PowerShell team had to make, but there wasn’t any choice. It’s one of the biggest cognitive bumps that experienced shell and script lan-guage users run into with PowerShell, but in the end, most people adapt without too much difficulty.