Chapter 2. Interactive PowerShell

PowerShell has two faces: interactivity and script automation. In this chapter, you will first learn how to work with PowerShell interactively. Then, we will take a look at PowerShell scripts.

Topics Covered:

• PowerShell as a Calculator
  • Calculating with Number Systems and Units
• Executing External Commands
  • Starting the “Classic” Console
  • Discovering Useful Console Commands
  • Security Restrictions
  • Special Places
• Cmdlets: PowerShell Commands
  • Using Parameters
  • Using Named Parameters
  • Switch Parameter
  • Positional Parameters
  • Common Parameters
• Aliases: Shortcuts for Commands
  • Resolving Aliases
  • Creating Your Own Aliases
  • Removing or Permanently Keeping an Alias
  • Overwriting and Deleting Aliases
• Functions: PowerShell-“Macros”
  • Calling Commands with Arguments
• Invoking Files and Scripts
  • Starting Scripts
• Running Batch Files
• Running VBScript Files
• Running PowerShell Scripts
• Summary

PowerShell as a Calculator

You can use the PowerShell console to execute arithmetic operations the same way you use a calculator. Just enter a math expression and PowerShell will give you the result:

You can use all of the usual basic arithmetic operations. Even parentheses will work the same as when you use your pocket calculator:

Note that PowerShell always uses the decimal point for numbers. Some cultures use other characters in numbers, such as a comma. PowerShell does not care. It always uses the decimal point. Using a comma instead of a decimal point will return something entirely different:

The comma always creates an array. So in this example, PowerShell created an array with the elements 4 and 3. It then adds the number 2 to that array, resulting in an array of three numbers. The array content is then dumped by PowerShell into the console. So the important thing to take with you is that the decimal point is always a point and not a comma in PowerShell.

Calculating with Number Systems and Units

The next arithmetic problem is a little unusual.

The example above calculates how many CD-ROMs can be stored on a DVD. PowerShell will support the common unit’s kilobyte (KB), megabyte (MB), gigabyte (GB), terabyte (TB), and petabyte (PT). Just make sure you do not use a space between a number and a unit.

Take a look at the following command line:

PowerShell can easily understand hexadecimal values: simply prefix the number with “0x”:

Here is a quick summary:

• Operators: Arithmetic problems can be solved with the help of operators. Operators evaluate the two values to the left and the right. For basic operations, a total of five operators are available, which are also called “arithmetic operators” (Table2.1).
• Brackets: Brackets group statements and ensure that expressions in parentheses are evaluated first.
• Decimal point: Fractions use a point as a decimal separator (never a comma).
• Comma: Commas create arrays and are irrelevant for normal arithmetic operations.
• Special conversions: Hexadecimal numbers are designated by the prefix “0x”, which ensures that they are automatically converted into decimal values. If you add one of the KB, MB, GB, TB, or PB units to a number, the number will be multiplied by the unit. Whitespace characters aren’t allowed between numbers and values.
• Results and formats: Numeric results are always returned as decimal values. You can use a format operator like -f if you’d like to see the results presented in a different way. This will be discussed in detail later in this book.

Executing External Commands

PowerShell can also launch external programs in very much the same way as the classic console. For example, if you want to examine the settings of your network card, you can enter the command ipconfig—it works in PowerShell the same way it does in the traditional console:

This following command enables you to verify if a Web site is online and tells you the route the data packets are sent between a Web server and your computer:

Starting the “Classic” Console

To temporarily switch back to the “classic” console, simply enter cmd (Enter). ). Since the old console is just another text-based command, you can easily launch it from within PowerShell. To leave the old console, you can type exit (Enter). Even PowerShell can be closed by entering exit. Most text-based commands use exit to quit. Occasionally, the command quit is required in commands instead of exit.

Discovering Useful Console Commands

The cmd command can be used for just one command when you specify the parameter /c. This is useful for invoking an old console command like help. This command has no external program that you can access directly from PowerShell. It’s only available inside the classic console. Using this command will return a list of many other useful external console commands:

You can use all of the above commands in your PowerShell console. To try this, pick some commands from the list. For example:

Security Restrictions

While you can launch notepad, you cannot launch wordpad:

Here, PowerShell simply did not know where to find WordPad, so if the program is not located in one of the standard system folders, you can specify the complete path name like this:

Since the path name includes whitespace characters and because PowerShell interprets them as separators, PowerShell is actually trying to start the program C:\program. So if path names include spaces, quote it. But that can cause another problem:

PowerShell now treats quoted information as string and immediately outputs it back to you. You can prefix it with an ampersand to ensure that PowerShell executes the quoted text:

Finally, WordPad starts.

Wouldn’t it be easier to switch from the current folder to the folder with the program we’re looking, and then launch the program right there?

This results in another red exception because PowerShell wants a relative or absolute path. So, if you don’t want to use absolute paths like in the example above, you need to specify the relative path where “.” represents the current folder:

Special Places

You won’t need to provide the path name or append the file extension to the command name if the program is located in a folder that is listed in the PATH environment variable. That’s why common programs, such as regedit, notepad, powershell,or ipconfig work as-is and do not require you to type in the complete path name or a relative path.

You can put all your important programs in one of the folders listed in the environment variable Path. You can find this list by entering:

As a clever alternative, you can add other folders containing important programs to your Path environment variables, such as:

After this change, you can launch WordPad just by entering its program name. Note that your change to the environment variable Path is valid only in the current PowerShell session. If you’d like to permanently extend Path, you will need to update the path environment variable in one of your profile scripts. Profile scripts start automatically when PowerShell starts and customize your PowerShell environment. Read more about profile scripts in Chapter 10.

• • Watch out for whitespace characters: If whitespace characters occur in path names, you can enclose the entire path in quotes so that PowerShell doesn’t interpret whitespace characters as separators. Stick to single quotes because PowerShell “resolves” text in double quotation marks, replacing variables with their values, and unless that is what you want you can avoid it by using single quotes by default.
  • Specifying a path: You must tell the console where it is if the program is located somewhere else. To do so, specify the absolute or relative path name of the program.
  • The “&” changes string into commands: PowerShell doesn’t treat text in quotes as a command. Prefix a string with “&” to actually execute it. The “&” symbol will allow you to execute any string just as if you had entered the text directly on the command line.

Cmdlets: PowerShell Commands

PowerShell’s internal commands are called cmdlets. The mother of all cmdlets is called Get-Command:

It retrieves a list of all available cmdlets, whose names always consist of an action (verb) and something that is acted on (noun). This naming convention will help you to find the right command. Let’s take a look at how the system works.

If you’re looking for a command for a certain task, you can first select the verb that best describes the task. There are relatively few verbs that the strict PowerShell naming conditions permit (Table 2.2). If you know that you want to obtain something, the proper verb is “get.” That already gives you the first part of the command name, and now all you have to do is to take a look at a list of commands that are likely candidates:

There is an approved list of verbs that are used with cmdlet names. You can list it with Get-Verb.

You can also look up help for any cmdlet using Get-Help:

You can easily discover cmdlets because Get-Command allows wildcards:

Using Parameters

Parameters add information so a cmdlet knows what to do. Once again, Get-Help will show you which parameters are supported by any given cmdlet. For example, the cmdlet Get-ChildItem lists the contents of the current sub-directory. The contents of the current folder will be listed if you enter the cmdlet without additional parameters:

For example, if you’d prefer to get a list of the contents of another sub-directory, you can enter the sub-directory name after the cmdlet:

You can use Get-Help to output full help on Get-ChildItem to find out which parameters are supported:

This will give you comprehensive information as well as several examples. Of particular interest is the “Parameters” section that you can also retrieve specifically for one or all parameters:

-Exclude <string[]>

Omits the specified items. The value of this parameter qualifies the Path parameter. Enter a path element or pattern, such as “*.txt”. Wildcards are permitted.

-Filter <string[]>

Specifies a filter in the provider’s format or language. The value of this parameter qualifies the Path parameter. The syntax of the filter, including the use of wildcards, depends on the provider. Filters are more efficient than other parameters, because the provider applies them when retrieving the objects, rather than having Windows PowerShell filter the objects after they are retrieved.

-Force <string[]>

Allows the cmdlet to get items that cannot otherwise not be accessed by the user, such as hidden or system files. Implementation varies from provider to provider. For more information, see about_Providers. Even using the Force parameter, the cmdlet cannot override security restrictions.

-Include <string[]>

Retrieves only the specified items. The value of this parameter qualifies the Path parameter. Enter a path element or pattern, such as “*.txt”. Wildcards are permitted.

The Include parameter is effective only when the command includes the Recurse parameter or the path leads to the contents of a directory, such as C:\Windows\*, where the wildcard character specifies the contents of the C:\Windows directory.

-LiteralPath <string[]>

Specifies a path to one or more locations. Unlike Path, the value of LiteralPath is used exactly as it is typed. No characters are interpreted as wildcards. If the path includes escape characters, enclose it in single quotation marks. Single quotation marks tell Windows PowerShell not to interpret any characters as escape sequences.

-Name <string[]>

Retrieves only the names of the items in the locations. If you pipe the output of this command to another command, only the item names are sent.

(…)

Using Named Parameters

Named parameters really work like key-value pairs. You can specify the name of a parameter (which always starts with a hyphen), then a space, then the value you want to assign to the parameter. Let’s say you’d like to list all files with the extension *.exe that are located somewhere in the folder c:\windows or in one of its sub-directories. You can use this command:

There are clever tricks to make life easier. You don’t have to specify the complete parameter name as long as you type as much of the parameter name to make it unambiguous:

Just play with it: If you shorten parameter names too much, PowerShell will report ambiguities and list the parameters that are conflicting:

Switch Parameter

Sometimes, parameters really are no key-value pairs but simple yes/no-switches. If they’re specified, they turn on a certain functionality. If they’re left out, they don’t turn on the function. For example, the parameter -recurse ensures that Get-ChildItem searches not only the -path specified sub-directories, but all sub-directories. And the switch parameter -name makes Get-ChildItem output only the names of files (as string rather than rich file and folder objects).

The help on Get-ChildItem will clearly identify switch parameters and place a “<SwitchParameter>” after the parameter name:

Positional Parameters

For some often-used parameters, PowerShell assigns a “position.” This enables you to omit the parameter name altogether and simply specify the arguments. With positional parameters, your arguments need to be submitted in just the right order according to their position numbers.

That’s why you could have expressed the command we just discussed in one of the following ways:

In all three cases, PowerShell will identify and eliminate the named arguments -recurse and -name first because they are clearly specified. The remaining arguments are “unnamed” and need to be assigned based on their position:

The parameter -path has the position 1, and no value has yet been assigned to it. So, PowerShell attaches the first remaining argument to this parameter.

The parameter -filter has the position 2. Consequently, it is assigned the second remaining argument. The position specification will make it easier to use a cmdlet because you don’t have to specify any parameter names for the most frequently and commonly used parameters.

Here is a tip: In daily interactive PowerShell scripting, you will want short and fast commands so use aliases, positional parameters, and abbreviated parameter names. Once you write PowerShell scripts, you should not use these shortcuts. Instead, you can use the true cmdlet names and stick to fully named parameters. One reason is that scripts can be portable and not depend on specific aliases you may have defined. Second, scripts are more complex and need to be as readable and understandable as possible. Named parameters help other people better understand what you are doing.

Common Parameters

Cmdlets also support a set of generic “CommonParameters”:

These parameters are called “common” because they are permitted for (nearly) all cmdlets and behave the same way.

Aliases: Shortcuts for Commands

Cmdlet names with their verb-noun convention are very systematic, yet not always practical. In every day admin life, you will want short and familiar commands. This is why PowerShell has a built-in alias system as it comes with a lot of pre-defined aliases. This is why in PowerShell, both Windows admins and UNIX admins, can list folder contents with commands they are accustom to using. There are pre-defined “historic” aliases called “dir” and “ls” which both point to the PowerShell cmdlet Get-ChildItem.

So, aliases have two important tasks in PowerShell:

• Historical: NFind and use important cmdlets by using familiar command names you know from older shells
• Speed: Fast access to cmdlets using short alias names instead of longer formal cmdlet names

Resolving Aliases

Use these lines if you’d like to know what “genuine” command is hidden in an alias:

$alias:Dir lists the element Dir of the drive alias:. That may seem somewhat surprising because there is no drive called alias: in the classic console. PowerShell supports many additional virtual drives, and alias: is only one of them. If you want to know more, the cmdlet Get-PSDrive lists them all. You can also list alias: like any other drive with Dir. The result would be a list of aliases in their entirety:

Get-Command can also resolve aliases. Whenever you want to know more about a particular command, you can submit it to Get-Command, and it will tell you the command type and where it is located.

You can also get the list of aliases using the cmdlet Get-Alias. You will receive a list of individual alias definitions:

You can use the parameter -Definition to list all aliases for a given cmdlet.

This will get you all aliases pointing to the cmdlet or command you submitted to -Definition.

As it turns out, there’s even a third alias for Get-ChildItem called “gci“. There are more approaches to the same result. The next examples find alias definitions by doing a keyword search and by grouping:

Creating Your Own Aliases

Set-Alias adds additional alias definitions. You can actually override commands with aliases since aliases have precedence over other commands. Take a look at the next example:

Edit typically launches the console-based Editor program. You can press (Alt)+(F) and then (X) to exit without completely closing the console window.

If you create a new alias called “Edit” and set it to “notepad.exe”, the command Edit will be re-programmed. The next time you enter it, PowerShell will no longer run the old Editor program, but the Notepad.

Removing or Permanently Keeping an Alias

How do you remove aliases? You don’t. All new aliases are discarded as soon as you exit PowerShell. All of your own aliases will be gone the next time you start PowerShell. “Built-in” aliases like “dir” and “cd” will still be there.

Try these options if you’d like to keep your own aliases permanently:

• Manually each time: Set your aliases after every start manually using Set-Alias. That is, of course, rather theoretical.
• Automated in a profile: Let your alias be set automatically when PowerShell starts: add your aliases to a start profile. You’ll learn how to do this in Chapter 10.
• Import and export: You can use the built-in import and export function for aliases.

For example, if you’d like to export all currently defined aliases as a list to a file, enter:

Because you haven’t entered any file names after Export-Alias, the command will ask you what the name are under which you want to save the list. Type in:

alias1 (Enter)

The list will be saved. You can look at the list afterwards and manipulate it. For example, you might want the list to include a few of your own alias definitions:

You can import the list to activate the alias definitions:

Import-Alias will notify you that it cannot create some aliases of the list because these aliases already exist. Specify additionally the option -Force to ensure that Import-Alias overwrites existing aliases:

Overwriting and Deleting Aliases

You can overwrite aliases with new definitions any time as long as an alias is not write-protected. Just redefine the alias with the cmdlet Set-Alias. Use this command if you’d like to remove an alias completely and don’t want to wait until you end PowerShell:

This instruction deletes the “Edit” alias. Here, the uniform provider approach becomes evident. The very same “Del” command will allow you to delete files and sub-directories in the file system as well. Perhaps you’re already familiar with the command from the classic console:

Functions: PowerShell-“Macros”

Aliases are simple shortcuts to call commands with another name (shortcut names), or to make the transition to PowerShell easier (historic aliases). However, the arguments of a command can never be included in an alias. You will need to use functions if you want that.

Calling Commands with Arguments

If you find yourself using the command ping frequently to verify network addresses, you may want to make this easier by creating a shortcut that not only calls ping.exe, but also appends standard arguments to it. Let’s see how you can automate this call:

Aliases won’t work here because they can’t specify command arguments. Functions can:

Unlike alias definitions, functions can run arbitrary code that is placed in brackets. Any additional information a user submitted to the function can be found in $args if you don’t specify explicit parameters. $args is an array and holds every piece of extra information submitted by the caller as separate array elements. You’ll read more about functions later.

Invoking Files and Scripts

To run files (like documents or scripts), PowerShell uses the same rules that apply to executables: either, you specify an absolute or relative path, or the file needs to be located in one of the special trustworthy folders defined in the Path environment variable.

Starting Scripts

Scripts and batch files are pseudo-executables. The script itself is just a plain text file, but it can be run by its associated script interpreter.

Running Batch Files

Batch files are text files with the extension “.bat”. They may include all the commands allowed in a classic cmd.exe console. When a batch file is opened, the classic console immediately starts to execute the commands it contains. Let’s check it out. First, create this test file:

Now enter this text:

Save the text and close Notepad. Your batch file is ready for action. Try to launch the batch file by entering its name:

The batch file won’t run. Because it has the same name and you didn’t specify any IP address or Web site address, the ping command spits out its internal help message. If you want to launch your batch file, you’re going to have to specify either the relative or absolute path name.

Your batch file will open and then immediately runs the commands it contains.

PowerShell has just defended a common attack. If you were using the classic console, you would have been tricked by the attacker. Switch over to the classic console to see for yourself:

If an attacker had smuggled a batch file named “ping.bat” into your current folder, then the ping command, harmless though it might seem, could have had catastrophic consequences. A classic console doesn’t distinguish between files and commands. It will look first in the current folder, find the batch file, and execute it immediately. Such a mix-up will never happen in the PowerShell console. So, return to your much-safer PowerShell environment:

Running VBScript Files

VBScript is another popular automation language as its scripts are tagged with the file extension “.vbs”. What we have just discussed about batch files also applies to these scripts:

Enter this VBScript code in Notepad and save it as test.vbs:

Next, run the script:

Running PowerShell Scripts

PowerShell has its own script files with the file extension “.ps1”. While you will learn much more about PowerShell scripts in Chapter 10, you already know enough to write your first script. Use the Windows editor to create and open your first script:

You can now enter any PowerShell code you want, and save the file. Once saved, you can also open your script with more sophisticated and specialized script editors. PowerShell comes with an editor called PowerShell ISE, and here is how you’d open the file you created with Notepad:

Try to run your script after you’ve created it:

You’ll probably receive an error message similar to the one in the above example. All PowerShell scripts are initially disabled. You need to allow PowerShell to execute scripts first. This only needs to be done once:

This grants permission to run locally stored PowerShell scripts. Scripts from untrusted sources, such as the Internet, will need to carry a valid digital signature or else they won’t run. This is to protect you from malicious scripts, but if you want to, you can turn this security feature off. Replace RemoteSigned with Bypass. The implications of signatures and other security settings will be discussed in Chapter 10. For now, the line above is enough for you to experiment with your own PowerShell scripts. To restore the original setting, set the setting to Undefined:

To get a complete picture, also try using the -List parameter with Get-ExecutionPolicy:

You now see all execution policies. The first two are defined by Group Policy so a corporation can centrally control execution policy. The scope “Process” refers to your current session only. So, you can use this scope if you want to only temporarily change the execution policy. No other PowerShell session will be affected by your change. “CurrentUser” will affect only you, but no other users. That’s how you can change this scope without special privileges. “LocalMachine,” which is the only scope available in PowerShell v.1, will affect any user on your machine. This is the perfect place for companies to set initial defaults that can be overridden. The default setting for this scope is “Restricted.”

The effective execution policy is the first policy from top to bottom in this list that is not set to “Undefined.” If all policies are set to “Undefined,” then scripts are prohibited.

Note: To turn off signature checking altogether, you can set the execution policy to “Bypass.” This can be useful if you must run scripts regularly that are stored on file servers outside your domain. Otherwise, you may get security warnings and confirmation dialogs. Always remember: execution policy exists to help and protect you from potentially malicious scripts. If you are confident you can safely identify malicious scripts, then nothing is wrong by turning off signature checking. However, we recommend not using the “Bypass” setting if you are new to PowerShell.

Summary

The PowerShell console can run all kinds of commands interactively. You simply enter a command and the console will return the results.

Cmdlets are PowerShell’s own internal commands. A cmdlet name is always composed of a verb (what it does) and a noun (where it acts upon).

To find a particular command, you can either guess or use Get-Command. For example, this will get you a list if you wanted to find all cmdlets dealing with event logs:

Search for the verb “Stop” to find all cmdlets that stop something:

You can also use wildcards. This will list all cmdlets with the keyword “computer”:

Once you know the name of a particular cmdlet, you can use Get-Help to get more information. This function will help you view help information page by page:

• Cmdlets are just one of six command types you can use to get work done:

• Alias: Shortcuts to other commands, such as dir or ls
• Function: “Macros” that run code and resemble “self-made” new commands
• Cmdlet: Built-in PowerShell commands
• Application: External executables, such as ipconfig, ping or notepad
• PowerShell scripts: Files with extension *.ps1 which can contain any valid PowerShell code
• Other files: Batch files, VBScript script files, or any other file associated with an executable

If commands are ambiguous, PowerShell will stick to the order of that list. So, since the command type “Alias” is at the top of that list, if you define an alias like “ping”, it will be used instead of ping.exe and thus can override any other command type.