Weekend Scripter: Learn How to Handle String Output from Within PowerShell

Summary: Microsoft Scripting Guy, Ed Wilson, discusses several different ways to handle string output from inside Windows PowerShell.

Microsoft Scripting Guy, Ed Wilson, is here. It is official—the 2012 Scripting Games are finally over (actually they were over yesterday, and I promised not to say any more about the games). Today the Scripting Wife and I are heading to Virginia Beach where I will speak at the Mark Minasi Conference. If you happen to be in the area, stop by and check it out. It will be a great conference, and I am really looking forward to it.

One of the things that beginners have a problem with is formatting output. In particular forming strings that contain data. One of the things Windows PowerShell does really well is handle input and output seamlessly. For example, many cmdlets automatically emit data. For example, the Get-Process cmdlet returns a nicely formatted table as shown here.

But things begin to go downhill really fast. Suppose you have a process named Notepad and you want to display the name and the process ID (PID). One way to approach this task is to use the Get-Process cmdlet to retrieve the instance of the Notepad process with which you are interested in working. Next you could store this process object into a variable, and then use expanding quotation marks (double quotation marks as opposed to literal quotation marks, which are single quotation marks) to expand the Name and ID properties. This technique is shown here.

PS C:\> notepad

PS C:\> $n = Get-Process notepad

PS C:\> "the name is $n.Name and the PID is $n.Id"

The problem is that when the string displays to the Windows PowerShell console, the object unravels and you do not get the property value that you might have been expecting to obtain. Instead, you get a jumble of letters that do not seem to make any sense. These commands and their associated output are shown here.

There are several ways to suppress the unraveling of the objects. One way is to use a subexpression. A subexpression is comprised of a dollar sign, and a pair of parentheses. The subexpression forces the evaluation of the object/property value and then returns the value of the property back to the string for display. A pair of parentheses causes Windows PowerShell to evaluate an expression prior to displaying the output. Therefore, it can display the contents of things like variables. A subexpression takes this a step further and causes the evaluation of the value of a property from an object. The syntax of this is shown here.

PS C:\> notepad

PS C:\> $n = Get-Process notepad

PS C:\> "the name is $($n.Name) and the PID is $($n.Id)"

the name is notepad and the PID is 2816

The command to start notepad, retrieve an instance of the object and store it in the $n variable, and display the property values is shown here with the associated output.

Another approach to this problem is to use concatenation. The concatenation operator is the plus sign (+). Concatenation glues the output together so it will display on the same line. By using concatenation, you place your string values inside quotation marks. You then close the quotation marks and call the object/property to display it. You then open another pair of quotation marks to add your additional string data. You continue with this pattern until you have completed displaying your data.

This approach to merging data from property values and strings is essentially unchanged from the earliest VBScript days. The big trick with this technique is that you must remember to include spacing between the string and the property value. If you do not, the concatenation operator will glue your string together. This approach is shown here.

PS C:\> notepad

PS C:\> $n = Get-Process notepad

PS C:\> "the name is " + $n.name + " and the PID is " + $n.id

The commands and the output associated with the commands are shown here.

A different problem exists when working with multiple objects. In this situation, the properties appear to disappear. This is because the process objects (in this example) hide inside an array and when attempting to access directly the property values. You must first deal with the array, and then you can work with the property values. If you do not first deal with the array, when you attempt to display the property values, nothing appears in the output. This situation is shown in the image here.

Because there are multiple objects in the array, it is necessary to walk through the array so that the individual values from the properties of the individual objects are accessible. The easiest way to accomplish this is to pipe the array of objects to the Foreach-Object cmdlet. In the script block portion of the Foreach-Object cmdlet, add the code from the previous examples. This technique is shown here (this example uses the % symbol, which is an alias for the Foreach-Object cmdlet).

PS C:\> 1..3 | % {notepad}

PS C:\> $n = Get-Process notepad

PS C:\> $n | % {"the name is " + $_.name + " and the PID is " + $_.id}

The code, from this technique, along with the associated output appears here.

You can use a similar technique to using the Foreach-Object cmdlet by using the ForEach language statement to walk through the array and display the property values. The ForEach language statement is a bit more complex to use than the Foreach-Object cmdlet, but it has the advantage of being a bit easier to read, and of being generally faster due to not involving the overhead of the pipeline. The use of the ForEach language statement to walk through the array is shown here.

PS C:\> 1..3 | % {start-process notepad -WindowStyle minimized}

PS C:\> $n = Get-Process notepad

PS C:\> foreach($a in $n) {"the name is " + $a.name + " and the PID is " + $a.id}

Because an array contains the objects, it is possible to index the array to display the property values. One easy way to do this is to use the same type of range operator that created the three instances of Notepad in the first place. When it is created, the $n variable stores the objects that are returned by the Get-Process cmdlet. The range operator passes the numbers that become the index indicators to select the specific element from the array. The dotted notation selects the applicable properties from the process object. This technique is shown here.

PS C:\> 0..2 | % {start-process notepad -WindowStyle minimized}

PS C:\> $n = Get-Process notepad

0..2 | % {"the name is " + $n[$_].name + " and the PID is " + $n[$_].id}

Rather than using concatenation or a subexpression to display the values from the object/property, a cleaner (and therefore, more reliable) method uses parameter substitution and the format operator. At first glance, this technique appears strange—although not necessarily any stranger than indexing into the array to retrieve the property values. When you become familiar with this technique, you may find that you like it better than using concatenation or a subexpression. The basic pattern is shown here.

This pattern with the associated output is shown in the following example.

PS C:\> "The first number {0} marks the first pattern" -f "zero"

The first number zero marks the first pattern

The advantage of using parameter substitution is that it is easier to format the output exactly as required. Going back to the example of indexing into the array, parameter substitution replaces the concatenation previously used. The revised example is shown here.

PS C:\> 0..2 | % {start-process notepad -WindowStyle minimized}

PS C:\> $n = Get-Process notepad

PS C:\> 0..2 | % {"The name is {0} and the PID is {1}" -f $n[$_].name, $n[$_].id}

The following output illustrates the use of parameter substitution to retrieve the property values from the array and to format the output.

Well, that is enough for now about formatting output. Join me tomorrow when I will continue the discussion by examining the use of various cmdlets.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy