Jeff Wouters's Blog

Lots of people that are used scripting languages, such as VBS or Kix, and start using PowerShell contact me about the infamous “Unexpected token ‘and’” error message.
I found this to be funny because I ran into that one myself in my early PowerShell days
So, lets go back in time to the point where I was just started using PowerShell and was playing around with it…

When creating a PowerShell script to find a file based on some criteria, my way of thinking would provide something like this:

$MSI = get-childitem $TargetPath –recurse | where ({$_.Extension -match “msi”} and {$_.Name -match “LiveMessenger”})

But… it will give an error stating that there is an “unexpected token ‘and’”… very annoying.
Since I was used to scripting in VBS, Batch and Kix I thought this was very strange, the syntax should have worked, right? Wrong…
PowerShell is an object based scripting language so a little bit of thinking needs to be changed, compared to what I would like to call ‘VBS thinking’.

With PowerShell it is possible to use the output of a first command as the input of the command that comes after it by using a technique called ‘piping’.
So, instead of using an ‘and’ statement, we could simply use the output of the first filter command as the input of the second filter command.
With this in mind, a change can be made. The following command uses the piping technique instead of an ‘and’ statement… and will work without that nasty “unexpected token ‘and’” error. Why? Simply because the ‘and’ statement is not being used anymore.

$MSI = get-childitem $TargetPath –recurse | where {$_.Extension -match “msi”} | where {$_.Name -match “LiveMessenger”}

And by using the piping technique, you can simply go even further and, if you would like that, you can filter even further!
Next to not getting an error, the piping technique is very CPU friendly compared to the ‘and’ statement.
The ‘and’ statement would cause the entire criteria to be tested on every single object, where the piping technique filters down the objects at every step which causes the list of objects for the second filter to be smaller… and so on. Far more elegant, right?

So, what does this all mean?
If you’re used to scripting languages like VBS or Kix, PowerShell will require a little change in your thinking. Don’t think about AND statements… instead, think about piping such as shown above

With PowerShell comes the ability to map drives to PSProviders through the command New-PSDrive. Some of the native PSProviders are FileSystem and Registry.
The New-PSDrive command also allows you to provide credentials (for example other than the one you are using to execute the script.

Now here comes the gotcha… Although the New-PSDrive command supports the -Credential parameter, the native PSProviders do not. Now what does that mean?
When you use the New-PSDrive command to, for example, create a drive mapping to a file share, let’s say to share on an AS400 system where you would need to use other credentials than the current logged on user, the mapping will fail stating that the parameter is not supported with the PSProvider. So, although the New-PSDrive supports the –Credential parameter the FileSystem PSProvider does not.
In the case of a mapping to a file share, an alternative for this is to use the good old net use for creating the mapping.

Microsoft has recognized this issue, but when you don’t know about this limitation it can cause some serious headache when you’re scripting. With this reason I wrote this post… just to make you aware of this issue.