ARTICLE

The Anatomy of a PowerShell Command

From Learn PowerShell in a Month of Lunches: Linux and macOS Edition by Travis Plunk

__________________________________________________________________

Take 37% off Learn PowerShell in a Month of Lunches: Linux and macOS Edition by entering fccplunk into the discount code box at checkout at manning.com.
__________________________________________________________________

When you start looking at PowerShell examples on the internet, it’s easy to get the impression that PowerShell is some kind of .NET–based scripting or programming language. Our fellow Microsoft Most Valuable Professional (MVP) award recipients, and hundreds of other PowerShell users, are pretty serious geeks who like to dig deep into the shell to see what we can make it do. But almost all of us began right where this article starts: running commands. This is what you’ll be doing in this article: not scripting, not programming, but running commands and command-line utilities.

Not scripting, but running commands

PowerShell, as its name indicates, is a shell. It’s similar to the Cmd.exe command-line shell which you’ve probably used previously, and it’s even similar to the good old MS-DOS shell that shipped with the first PCs back in the 1980s. It has a strong resemblance to the UNIX shells, such as Bash, from the late 1980s, or even the original UNIX Bourne shell, introduced in the late 1970s. PowerShell is much more modern, but in the end, PowerShell isn’t a scripting language in the way JavaScript or Python are.

With those languages, as with most programming languages, you sit down in front of a text editor (even if it is Windows Notepad) and type a series of keywords to form a script. You save that file, and perhaps double-click it to test it. PowerShell can work like that, but this isn’t necessarily the main usage pattern for PowerShell, particularly when you’re getting started. With PowerShell, you type a command, add a few parameters to customize the command’s behavior, hit Enter, and immediately see your results.

Eventually, you’ll get tired of typing the same command (and its parameters) over and over again, and you’ll copy and paste it all into a text file. Give that file a .PS1 filename extension, and you suddenly have a PowerShell script. Now, instead of typing the command over and over, you run that script, and it executes whatever commands are inside. It’s typically far less complex than scripting or programming. In fact, it’s a similar pattern to that used by UNIX administrators for years. Common UNIX/Linux shells, such as Bash, have a similar approach: Run commands until you get them right, and then paste them into a text file and call it a script.

Don’t get us wrong: You can get as complex as you need to with PowerShell. It supports the same kind of usage patterns as Python and other scripting or programming languages. PowerShell gives you access to the full underlying power of .NET Core, and we’ve seen PowerShell “scripts” which were practically indistinguishable from a C# program written in Visual Studio. PowerShell supports these different usage patterns because it’s intended to be useful to a wide range of audiences. The point is that because it supports this level of complexity doesn’t mean that you have to use it at that level, and it doesn’t mean you can’t be extremely effective with less complexity.

Here is an analogy: You probably drive a car. If you’re like us, changing the oil is the most complex mechanical task you’ll ever do with your car. We’re not car geeks and can’t rebuild an engine. We also can’t do those cool, high-speed J-turns that you see in the movies. You’ll never see us driving a car on a closed course in a car commercial. That we’re not professional stunt drivers doesn’t stop us from being extremely effective drivers at a less complex level. Someday we might decide to take up stunt driving for a hobby (our insurance companies will be thrilled), and at that point we’ll need to learn a bit more about how our cars work and master some new skills. The option is always there for us to grow, but for now, we’re happy with what we can accomplish as normal drivers.

For now, we’ll stick with being normal “PowerShell drivers,” operating the shell at a lower level of complexity. Believe it or not, users at this level are the primary target audience for PowerShell, and you’ll find that you can do a lot of incredible stuff without going beyond this level. All you need to do is master the ability to run commands within the shell, and you’re on your way.

The anatomy of a command

Figure 1 shows the basic anatomy of a complex PowerShell command. We call this the full-form syntax of a command. We’re showing a somewhat complex command in figure 1, and you can see all of the things that might show up.

Figure 1. The anatomy of a PowerShell command

To make sure you’re completely familiar with PowerShell’s rules, let’s cover each of the elements in the previous figure in more detail:

• The cmdlet name is Get-Command. PowerShell cmdlets always have this verb-noun naming format.
• The first parameter name is -LogName, and it’s being given the value Security. Because the value doesn’t contain any spaces or punctuation, it doesn’t need to be in quotation marks.
• The second parameter name is -ComputerName, and it’s being given two values: WIN8 and SERVER1. These are in a comma-separated list, and because neither value contains spaces or punctuation, neither value needs to be inside quotation marks.
• The final parameter, -Verbose, is a switch parameter. That means it doesn’t get a value; specifying the parameter is sufficient.
• Note that there’s a mandatory space between the command name and the first parameter.
• Parameter names always start with a dash (–).
• There’s a mandatory space after the parameter name, and between the parameter’s value and the next parameter name.
• There’s no space between the dash (–) that precedes a parameter name and the parameter name itself.
• Nothing here is case-sensitive.
• Get used to these rules. Start being sensitive about accurate, neat typing. Paying attention to spaces and dashes and other rules will minimize the silly errors that PowerShell throws at you.

That’s all for this article. If you want to learn more about the book, check it out on our browser-based liveBook reader here.

Find more free content from our titles at Manning’s Free Content Center: https://freecontent.manning.com/