Commands in PowerShell

Commands do the work in PowerShell. Its that simple yet when I speak about PowerShell and SharePoint there always seems to be some confusion on what a command is. That’s understandable because in PowerShell there are many ways to execute a command. Yesterday I was speaking with someone and started talking about functions and filters in PowerShell. The person whom I was speaking with had not worked with functions or filters but understood cmdlets and providers.

It seems that if I want to create posts on PowerShell and SharePoint I need to preface it with a post on commands. This way as you read my PS/SP posts you can better understand the commands I use. Don’t consider this “the” blog post on PowerShell commands but a simple primer to help clear the ambiguities.

First commands causes actions to happen in PowerShell. Commands allow us to accomplish tasks from listing the files on a file system to opening a text file in notepad. The concept of a command in a “command line” application is not new and probably not confusing. What might be considered confusing is that PowerShell has four basic types of commands. To make things a little more interesting commands of one type can interact with commands of other types.

The four basic command types in PowerShell are:
1) Cmdlets
2) Functions
3) Native
4) Scripts

Cmdlets
The standard demo command for PowerShell appears to be get-process. Get-process cmdlet will ultimately dump process information to the host ( screen). Get-Process is a cmdlet (pronounced command-let). Cmdlets support a normalized naming scheme with the verb-noun syntax. Cmdlets are compiled code that are available to the PowerShell environment. PowerShell has “built-in” cmdlets such as get-process, get-help and where-object to name a very few. Developers can create new cmdlets and register them with the PowerShell host.

To run a simple cmdlet in PowerShell

1. Open PowerShell
2. Type Get-Process at the PowerShell Prompt.
3. Click Enter to execute the cmdlet.

Figure 1: Executing a Cmdlet in PowerShell Host

Functions
Functions organize commands and statements into a reusable chunk of code. Here is an example of a function in PowerShell:

Function WriteDBGFooter
{
“Darrin Bishop Group, Inc.”
“www.darrinbishop.comblog”
}

Functions are compiled when they are defined in the host and are generally available until you restart the host. Functions can take parameters.

To create and execute the WriteDBGFooter function defined above

1. Type the function into the PowerShell Host
PowerShell allows you to add returns while typing. It is “smart enough” to know when the commands are complete. When it is expecting more characters it will display a >> prompt. So you are free to type in a multiline function without PowerShell attempting to execute a partial function. You will need to type one more return at the end of the function to let PS know you are done entering the functions.
2. Type WriteDBGFooter
3. Press Enter to execute

The result should be similar to Figure 2 below. You should be able to use WriteDBGFooter for the life of the PowerShell session without rekeying the function.

Figure 2: PowerShell Function Defined and Executed

Native
Native commands are simple. Native commands are those that run outside the PowerShell process. When you open a .docx file in Microsoft Word you are using a native command.

To execute a Native command:

1. In PowerShell host enter the path to a Word document
2. Enter to Execute

Figure 3 and 4 below displays the PowerShell host and the resulting Word document.

Figure 3: Executing a Native Command

Figure 4:Document Opened in Word

Scripts
Script commands are simply commands that have been saved to the file system. Scripts are commonly saved with a .ps1 extension. Scripts let us save a commonly used set of commands to a file so that we can run it many times without rekeying the script. Scripts are called from PowerShell by file name. If your PowerShell’s current location is the same as the location of the script you can execute the script by placing a ./ in front o the script name. The ./ is required when your current PowerShell location is the same as the script location.

One other interesting thing to know about scripts is that scripts will not run by default. PowerShell allows you to set a script execution policy. By default scripts must be signed before they can run. By calling the set-executionpolicy passing in unrestricted value you can bypass this security block. Ofcourse you should really think about what you are doing when you decide to do this. The PowerShell team placed this in the host for a reason.

To set the Execution Policy

1. Type set-executionpolicy -ExecutionPolicy Unrestricted
2. Click Enter to execute.

(Note, if you are running Vista you might need to run PowerShell as an administrator to make this policy change)

To demonstrate a script I will explain how to create a script that looks at the Application event log and counts the number of Outlook events .

1. Open Notepad
2. Type into Notepad the following commands

$logItemCount = (get-eventlog -logName Application | Where-Object {$_.Source -eq “Outlook”} ).count
“You have $logItemCount Outlook items in the Application event log.”

3. Save the file as GetOutlookLogItems.ps1 . For this example I have saved GetOutlookLogItems.ps1 to c:PSScripts.
4. Type c:PSScriptsGetOutlookLogItems.ps1
5. Click Enter to execute

Figure 5 displays the script in Notepad and Figure 6 displays the PowerShell console after executing the script.

Figure 5: Creating a Script

Figure 6: Executing a Script

That’s a very basic overview of the command types in PowerShell. I really boils down to executing commands in the PowerShell host regardless of the command type. Cmdlets are great if there is one that works for your situations. I use functions a lot to script against an object model because I do not have to compile or register a function like a custom cmdlet ( I do build and use custom cmdlets when it suits me). Functions are a great way to quickly encapsulate one or more commands for reuse I use scripts to roll up many commands and functions to achieve a particular objective. With scripts I can create, test, fix and then reuse whenever I need the script.