PowerShell Essentials (Part 4)

If you would like to read the other parts in this article series please go to:

Back in one of the earlier articles in this series, I listed several questions that I planned to answer in an effort to help my readers to achieve proficiency in Windows PowerShell. Here is the list of questions once again.

How can I figure out which cmdlet toUsee?
How do I specify parameters for a cmdlet?
How can I get help with using a cmdlet?
How can I retrieve information about an object?
Why do some blocks of code not appear to be written in PowerShell?
How do PowerShell Scripts work?
Can I use variables?
How do PowerShell functions work?

I have already answered a few of the questions from the list, so in this article I want to continue the discussion by answering the question of why some blocks of code appear to not be written in PowerShell.

As you have probably already figured out, I spend a lot of time working with PowerShell. Even though I definitely know my way around PowerShell, I sometimes find myself visiting sites like MSDN or TechNet looking for scripts that can be used to accomplish various tasks. After all, why reinvent the wheel if someone else has already posted a solution to the task.

I have to admit that the first few times that I downloaded a PowerShell script from TechNet, I was a little taken back. The scripts were only vaguely similar to PowerShell (at least as I understood the PowerShell syntax rules). I wasn’t even completely sure that I was looking at PowerShell code.

There are actually a number of different things that can cause a block of PowerShell code to look a lot different from what you have seen so far in this article series. Some of the things that can make PowerShell look completely foreign include:

Variables
Abbreviations
Operators
Comments
Scopes

I’m not going to talk about scopes in this article series because scopes are a more advanced topic (I plan on eventually writing a separate series that covers advanced scripting), and variables are going to be discussed later in this series. For right now though, let’s take a look at abbreviations, operators, and comments.

Comments

Comments are simply lines of readable text that are inserted into a PowerShell script for documentation purposes. A comment always begins with a pound sign (#). Everything after the comment is ignored by PowerShell. Comments only exist as a way of documenting what a script does. Here is an example of a PowerShell comment:

# This is a comment line.

Abbreviations

PowerShell abbreviations are simply a way to shorten a PowerShell cmdlet so as to reduce the amount of typing required. I have to admit that PowerShell abbreviations are a bit of a pet peeve for me. I almost always prefer to write PowerShell code in long form because I think that doing so results in code that is more readable and easier to understand. Even so, abbreviations are common enough that it helps to familiarize yourself with them.

Let me show you an example of how a PowerShell abbreviation works. Suppose for a moment that I wanted to create a list of all of the virtual machines that exist on a Hyper-V server and then format the information in table form. I could accomplish this task with the following command:

Get-VM | Format-Table

The Get-VM portion of the command retrieves the list of VMs. The next thing that you see is the pipe symbol (|). The pipe symbol is used to combine two cmdlets. The pipe symbol causes the output from the first cmdlet to act as input for the second cmdlet. So in this case, we are taking the output from the Get-VM cmdlet and using it as input for the Format-Table cmdlet, which controls how the resulting data is displayed. You can see what this looks like in Figure A.

Figure A: The Get-VM | Format-Table command creates a table displaying Hyper-V virtual machines.

So now that I have shown you how the Get-VM | Format-Table command works, let’s get back to the discussion of PowerShell abbreviations. The Format-Table cmdlet is often abbreviated FT. Hence, the command could be shortened to:

Get-VM | FT

As you can see, the abbreviated command barely resembles PowerShell. As you can see in Figure B, the abbreviated command delivers the same output as the long form command. Another example is that Format-List is often abbreviated as FL.

Figure B: The Get-VM | Format-Table command can be shortened to Get-VM | FT.

Operators

Operators can be another source of confusion within PowerShell. Operators are comparative functions such as greater than, less than, or equal to. The reason why operators are sometimes confusing is that the most common operators are expressed in an abbreviated form.

The operators that are used within PowerShell include:

EQ (Equal)
NE (Not Equal)
GT (Greater Than)
GE (Greater Than or Equal To)
LT (Less Than)
LE (Less Than or Equal To)
Like
NotLike
Match
NotMatch
Contains
NotContains
In
NotIn
Replace

Admittedly, some of these operators are more commonly used than others. The most commonly used operators tend to be –EQ, -NE, -GT, -GE, -LT, and –LE.

Since operators are such a big part of PowerShell, I want to take a few minutes and show you how some of these operators work.

PowerShell operators are used as a question. For example, you can ask if A is greater than B. The answer is sometimes Boolean (True / False) or it may be numerical. PowerShell is usually smart enough to figure out which type of answer makes the most sense.

Suppose for instance, that I wanted to know if 6 was greater than 8. I could pose the question as:

6 –GT 8

PowerShell would return an answer of false. Now suppose that I wanted to provide PowerShell with a list of numbers and then determine which of those numbers was greater than 8. I could use a command like this one:

6, 7, 8, 9 –GT 8

In this case, PowerShell would give me an answer of 9 rather than giving me a True / False answer. You can see an example of this in Figure C.

Figure C: PowerShell can give answers in various formats.

You can also use the asterisks symbol as a wildcard. This tends to be especially helpful when it comes to matching comparisons. Take this one for example:

“Windows PowerShell” –Like “*Power*”

In this case, there would be a response of True.

You can also treat the Like operator as a “which one is like” operator. Suppose for example that I wanted to know whether the word Windows or the word PowerShell was like the word Power. I could find out by using a command like this one:

“Windows”, “PowerShell” –Like “*Power*”

The response should be PowerShell. You can see an example of this in Figure D.

Figure D: The Like operator can be used for comparisons.

Conclusion

In this article, I have explained why some blocks of code might not look the way that you would expect PowerShell code to appear. In the next article in this series, I will continue the discussion by showing you how variables work. From there, we will move on to building some PowerShell scripts.

If you would like to be notified when Brien Posey releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.

If you would like to read the other parts in this article series please go to: