4 Running commands

 

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 chapter starts: running commands. That’s what you’ll be doing in this chapter: not scripting, not programming, but running commands and command-line utilities.

4.1 Let’s talk security

Okay, it’s time to talk about the elephant in the room. PowerShell is great, and PowerShell is awesome. But the bad guys like PowerShell just as much as we do. Securing your production environment is at the top of everyone’s priority list. By now, you’re probably starting to get a feel for how powerful PowerShell can be—and you’re wondering whether all that power might be a security problem. It might be. Our goal in this section is to help you understand exactly how PowerShell can impact security in your environment and how to configure PowerShell to provide exactly the balance of security and power you require.

4.1.1 Execution policy

4.2 Not scripting, but running commands

4.3 The anatomy of a command

4.4 The cmdlet naming convention

4.5 Aliases: Nicknames for commands

4.6 Taking shortcuts

4.6.1 Truncating parameter names

4.6.2 Using parameter name aliases

4.6.3 Using positional parameters

4.7 Support for external commands

4.8 Dealing with errors

4.9 Common points of confusion

4.9.1 Typing cmdlet names

4.9.2 Typing parameters

4.10 Lab

4.11 Lab answers