Search results for 'app:weblogs' matching tags 'Getting Started' and 'Strings'

Variable Substitution in a PowerShell Script Block

Anonymous — Wed, 22 May 2013 05:00:00 GMT

Summary: Microsoft Scripting Guy, Ed Wilson, talks about performing variable substitution inside a Windows PowerShell script block.

Hey, Scripting Guy! I am trying to create a command. The command contains variables that I would like to assign prior to creating the command. However, when I get to the script block portion of my code, it does not do the variable substitution for the value the way an expanding string normally works. Can you help me?

—SW

Hello SW,

Microsoft Scripting Guy, Ed Wilson, is here. Last week at the first ever Northern Virginia PowerShell User Group, the Scripting Wife and I found a great little tea shop. I can’t help but thinking about the scone I got there—it was pretty good.

Expanding variable values

One of the really cool things about Windows PowerShell is the expanding strings—I absolutely love them. It surely beats having to do lots of string concatenation like I had to do back in the VBScript days. To illustrate this technique, I assign a string to the value of a variable—in this case, the $a variable. I look at the value contained in the variable. This code is shown here.

PS C:\> $a = "This is a string"

PS C:\> $a

This is a string

Now, by using the expanding string, I can see the value that is contained inside the $a variable. To suppress the variable expansion, I escape it with the grave accent character as shown here.

PS C:\> "The value of `$a is $a"

The value of $a is This is a string

The problem with a script block

If, on the other hand, I want to expand the value of a variable inside a script block, it does not work. This is shown in the code that follows.

PS C:\> $a = "This is a string"

PS C:\> $a

This is a string

PS C:\> $b = {"The value of `$a is $a"}

PS C:\> $b

"The value of `$a is $a"

Solving the problem with variable expansion in a script block

The solution to expanding a variable inside a script block is to do two things. First create the script block as an expanding string. This is shown here:

PS C:\> $a = "This is a string"

PS C:\> $a

This is a string

PS C:\> $b = "The value of `$a is $a"

PS C:\> $b

The value of $a is This is a string

Now, I use the static Create method from the [scriptblock] class. This will create a script block. To do this, I use the [scriptblock] class and then call the Create method while passing the string contained in the $b variable. This is shown here.

PS C:\> [scriptblock]::Create($b)

The value of $a is This is a string

I can confirm that it is in fact a script block by piping the results to the Get-Member cmdlet as shown here:

PS C:\> [scriptblock]::Create($b) | gm

TypeName: System.Management.Automation.ScriptBlock

Name MemberType Definition

---- ---------- ----------

CheckRestrictedLanguage Method void CheckRestrictedLanguage(System.Collection...

Equals Method bool Equals(System.Object obj)

GetHashCode Method int GetHashCode()

GetNewClosure Method scriptblock GetNewClosure()

GetObjectData Method void GetObjectData(System.Runtime.Serializatio...

GetPowerShell Method powershell GetPowerShell(Params System.Object[...

GetSteppablePipeline Method System.Management.Automation.SteppablePipeline...

GetType Method type GetType()

Invoke Method System.Collections.ObjectModel.Collection[psob...

InvokeReturnAsIs Method System.Object InvokeReturnAsIs(Params System.O...

ToString Method string ToString()

Ast Property System.Management.Automation.Language.Ast Ast ...

Attributes Property System.Collections.Generic.List[System.Attribu...

File Property string File {get;}

IsFilter Property bool IsFilter {get;set;}

Module Property psmoduleinfo Module {get;}

StartPosition Property System.Management.Automation.PSToken StartPosi...

Now, the cool thing about this is that I can also store the script block into another variable. This is shown here:

$sb = [scriptblock]::Create($b)

After I have stored the script block into the variable, I can also call any of the methods or properties of the script block. For example, here is the AST:

PS C:\> $sb.Ast

ParamBlock :

BeginBlock :

ProcessBlock :

EndBlock : The value of $a is This is a string

DynamicParamBlock :

ScriptRequirements :

Extent : The value of $a is This is a string

Parent :

It is not horribly exciting in this example, but for more complex code, it is definitely exciting stuff. We have a great Hey, Scripting Guy! Blog post written by Bartek Bielawski, which offers several good ideas for further exploration: Learn How IT Pros Can Use the PowerShell AST.

SW, that is all there is to using variable expansion and substitution in a Windows PowerShell script block. Join me tomorrow when I will talk about way cool Windows PowerShell stuff.

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

Weekend Scripter: Handle the PowerShell Pipeline and Use the Console

Anonymous — Sun, 29 Apr 2012 05:00:00 GMT

Summary: Microsoft Scripting Guy, Ed Wilson, talks about handling output to the Windows PowerShell console while using the pipeline.

Microsoft Scripting Guy, Ed Wilson, is here. The Scripting Wife and I are enjoying Virginia Beach. We have met some really cool and smart people here at the Mark Minasi Conference. We had a chance to go to the huge naval museum here. It was cool. In the museum, they have different types of exhibits. Some of them have a button that you push, and you listen to it, then you go to the next exhibit. Others have drawings and diagrams that you read, and then you go to the next exhibit. Still others have brochures that you can skim and take with you when you leave the museum.

In a way, Windows PowerShell output behaves the save way. Some things we write to the Windows PowerShell console, others we write to files. Some things display to the console and write to files, and still others appear and then they are gone, never to return. It is the ease-of-use plus the diversity of options for creating output from inside Windows PowerShell that is a source of confusion for beginning (and even for some advanced) Windows PowerShell scripters. Simply put…

Like the child who comes home from the grocery store with a loaf of bread and 12 candy bars, we often do not make the best choices. Just like the child with the dozen candy bars and a loaf of bread, some of the options seem too compelling. We get over-awed with the choices—in short, we zone out into a sort of geek trance. In the following command, I use the Get-Command cmdlet, the Sort-Object cmdlet, the Select-Object cmdlet, and the Format-Wide cmdlet to produce a list of the more common output and formatting cmdlets. Twenty cmdlets appear on this list (Measure-Command tells me that). The dizzying array of choices are shown here.

PS C:\> gcm -Verb write, out, tee, format | sort verb | select name | fw -a

Format-Table Format-Wide Format-Custom Format-List Out-Null

Out-Printer Out-String Out-Host Out-Default Out-File

Out-GridView Tee-Object Write-Progress Write-Output Write-Warning

Write-Verbose Write-Error Write-Debug Write-Host Write-EventLog

The easiest way to write output

The easiest way to write output is not to use any of the twenty cmdlets listed previously. Rather, it is to place the output into a string. There are two types of strings in Windows PowerShell, the expanding string and the literal string. The difference is twofold; an expanding string uses double quotation marks, and a literal string uses single quotation marks. The practical application of these different types of strings is also twofold. A literal string means that what you type is what you get. This is, in fact, the way that strings worked in other languages (for example in VBScript). The difference, with VBScript anyway, is that the string indicator was the double quotation mark.

Using literal strings

The following example illustrates how a literal string works. It uses single quotation marks and contains a variable. When the string displays to the Windows PowerShell console, the variable appears exactly as typed. That is, the variable does not expand to display the value that the variable contains.

In the following example, in the first line, a string assigns to the variable $a. The double quotation marks do this, but you could just as easily (and with no difference in the outcome of the code) use single quotation marks for this string. This is because the string contains no variables to expand. In the second line of code, a pair of single quotation marks delineates the string. This time, the string contains two variables. The output displays to the Windows PowerShell concole, but the values contained inside the $a variables do not unravel. Instead, only the literal $a appears on the outputted line.

PS C:\> $a = "this is a string contained in a variable"

PS C:\> 'The value of the $a variable is actually $a'

The value of the $a variable is actually $a

PS C:\>

Using expanding strings

If you replace the single quotation marks in the second line of code with double quotation marks, the difference is dramatic. For each of the two locations where the $a variable appears in the code, the value contained in the variable replaces the literal variable name. The resulting output is not very useful, but it is different.

PS C:\> "The value of the $a variable is actually $a"

The value of the this is a string contained in a variable variable is actually this

is a string contained in a variable

PS C:\>

Suppress automatic expansion

What you might want to do is to use the expanding or unraveling feature of the expanding string for the second appearance of the $a variable, but suppress it for the first appearance. To suppress the expansion of the first variable, use the grave accent (also called back-tick) character (`) immediately prior to the first appearance of the $a variable. This is shown here.

PS C:\> "The value of the `$a variable is actually $a"

The value of the $a variable is actually this is a string contained in a variable

PS C:\>

These examples of using literal and expanding strings are shown with their associated output in the image that follows.

Writing output to the console

Most of the time, beginners who are learning Windows PowerShell use the Write-Host cmdlet to display output to the Windows PowerShell console. One reason for doing this is that people coming from a VBScript background (where they used “Wscript.Echo” to write output) feel that they need to do something similar to this. They find Write-Host, and they see it as the direct replacement. Next, they proceed with a line-by-line adaptation of their previous VBScript to the new Windows PowerShell script. Unfortunately, this does not take advantage of an inherent Windows PowerShell strength —it works with objects, not strings.

There are occasions when using Write-Host is the right thing to do. For example, if you are at the end of a command and you want to take advantage of the Foreground or the Background color abilities of the Write-Host cmdlet, the command makes sense. On the other hand, if you are not using the color capabilities of the Write-Host cmdlet, it makes sense to use the Write-Output cmdlet instead. The reason is that Write-Host is a terminal cmdlet—that is, after you use it, you can do nothing else. If you try to pipe the output from the Write-Host cmdlet to a text file, no error generates, but the text file is empty. This is because no objects return from the Write-Host cmdlet. The commands are shown here.

The Out-File cmdlet creates the writehost.txt file, but because Write-Host passes no objects along the pipeline, the text file contains no text. The empty file is shown here.

Choosing both console and file

You do not need to write complicated duplicate code to write data to the Windows PowerShell console and to write to a file. In fact, you do not need to store the data in an intermediate variable—it can be done with a single command. The cmdlet to use is Tee-Object. The Tee-Object cmdlet accepts a single input and then splits the output to multiple locations. It can display data to the Windows PowerShell console and write it to a file. It can also display to the console and write back to a variable. The basic syntax is shown here.

"output from the Tee-Object" | Tee-Object -FilePath c:\fso\tee.txt

The command and its associated output are shown in the following image.

A quick check of the text file reveals that the text file does indeed contain the text output to the console. The Tee.txt file is shown here.

You are not limited to only sending the output to the Windows PowerShell console and a file, or to a variable and the console. This is because the cmdlet splits the output. You can use a variable to hold part of the output, and you can still send it to a text file. When you have the output in a variable, you can easily display the contents of the variable to the console. This is shown here.

PS C:\> $t = "output from the Tee-Object. Test 2" | Tee-Object -FilePath c:\fso\tee2.

txt

PS C:\> $t

output from the Tee-Object. Test 2

PS C:\>

That is about all there is for now. 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

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

Anonymous — Sat, 28 Apr 2012 05:00:00 GMT

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.

Opening quotation mark	Parameter to replace	Format operator	Value to substitute for first parameter	Closing quotation mark
“	{0}	-f	zero	”

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.

Ed Wilson, Microsoft Scripting Guy