Search results for 'app:weblogs' matching tags '2011 Scripting Games' and 'getting started'

Writing Output with PowerShell

Anonymous — Tue, 17 May 2011 05:00:00 GMT

Summary: Microsoft PowerShell MVP, Marco Shaw, discusses writing output from Windows PowerShell.

Microsoft Scripting Guy, Ed Wilson, is here. Today we will be joined by Marco Shaw.

Marco is a consultant with CGI in Moncton. He has been working in the IT industry for over 12 years, also working for Bell Aliant and Atlantic Lottery. He was awarded the Microsoft MVP award for his contributions to the Windows PowerShell community in 2007, 2008, 2009, and 2010. His recent authoring activities have included writing Windows PowerShell content for a Windows Server 2008 book published by Microsoft Press and writing a Windows PowerShell-related article on System Center Operations Manager 2007 for TechNet Magazine. He also provided Windows PowerShell content for a SQL Server 2008 book by SAMs publishing company and for a just released revised edition of System Center Operations Manager 2007 Unleashed by SAMs. He also coauthored the 2nd edition of PowerShell Unleashed published by SAMs, which was released early in 2009. He has spoken at Microsoft TechDays in Halifax, Canada the last two years where he has delivered sessions on System Center Operations Manager 2007 R2, Windows Server 2008 R2, and Windows PowerShell.

Using Write-Host and Write-Output

When writing scripts, I’ll typically use simple quotation marks to wrap anything I want to display on the screen, but there are two cmdlets in particular that provide some extra features and can be very useful when creating scripts: Write-Host and Write-Output.

Of the two, Write-Host is typically the only one I frequently use—in particular with its NoNewLine switch. What NoNewLine provides is a simple way to join different lines together.

Here is a simple code example to demonstrate:

Write-Host –NoNewLine "Counting from 1 to 9 (in seconds): "

foreach($element in 1..9){

Write-Host –NoNewLine "${element} "

Start-Sleep –Seconds 1

}

Write-Host ""

The following image shows the output of running the script. If you try running the script on your own, you will notice that it appears to be a simple counter.

Now, there are countless ways I could have accomplished this, for example, building a simple string or simply clearing the screen each time.

Something else that Write-Host is useful for is when one might want to add color in their output. This can be very useful when trying to make output stand out or even just to get really flashy stuff on screen. I am going to build on the previous code snippet and blend in some colors as the numbers change.

Write-Host –NoNewLine "Counting from 1 to 9 (in seconds): "

foreach($element in 1..3){

Write-Host –NoNewLine "${element} " -BackgroundColor "Green" -ForegroundColor "Black"

Start-Sleep –Seconds 1

}

foreach($element in 4..6){

Write-Host –NoNewLine "${element} " -BackgroundColor "Yellow" -ForegroundColor "Black"

Start-Sleep –Seconds 1

}

foreach($element in 7..9){

Write-Host –NoNewLine "${element} " -BackgroundColor "Red" -ForegroundColor "Black"

Start-Sleep –Seconds 1

}

Write-Host ""

The following image shows the result of running the previous code. The coloring uses good old traffic light colors to show the progression in groups of three. I have also changed the color in the text displayed on the console to make it clearer to see against the background colors.

OK, that was fun…

Now, let us dig a bit deeper. In Windows PowerShell, the host is what you, as a user, interact with. You will typically interact with the two default hosts: the Windows PowerShell console and the Windows PowerShell Integrated Scripting Environment (ISE).

When you use Write-Host, you are telling Windows PowerShell to simply display something in the host to the user. But what happens with Write-Host output if I’m running a script from a scheduled task or even if I do something simple like redirect my script by using the standard redirection operator (>)? In these cases, (an example is coming up), what Write-Host prints out is basically lost. In other words, if you are not watching your script when it actually is running, Write-Host is not doing a whole lot for you. Basically, it is displaying information to the screen, and then “throwing it away.”

There is an excellent example that Don Jones’ wrote a few years ago (for more information, see Welcome to Concentrated Technology). You can see this by looking over the following image.

In the previous image, I have used several commands. The important thing to notice between the first and second command is that in the first one, it appears that the Where-Object cmdlet doesn’t work! In fact, it is working fine, and just doing what it is told. The important thing to note is what I said about Write-Host “displaying stuff and throwing it away.” Write-Host is the cmdlet that is responsible for displaying the numbers on the screen, and Where-Object actually gets nothing at all sent to it because of the use of Write-Host.

In the second command, things work as one might expect. The objects are passed along the pipeline so Where-Object actually works in this case, and it is able to filter the objects properly because Write-Output was used instead.

The above image also shows the output from a third and fourth command. They are included to show how Write-Output is basically always there without having to be explicitly added. Windows PowerShell does a lot of things behind the scenes for you, and this is just one example of this.

Another simple example to show the contract between the two cmdlets is to show an example that uses output redirection. Consider the following code snippet.

Write-Host "Phase 1"

$start=Get-Date

Write-Output $start

Write-Host "Phase 2"

Start-Sleep -Seconds 5

Write-Host "Phase 3"

$end=Get-Date

Write-Output $end

Write-Host "Phase 4"

$diff=New-TimeSpan $start $end

Write-Output $diff

The following image shows this script being run two different ways.

As can be seen in this image, Write-Host really does just that, and nothing more.

I hope that I have helped clarify the differences between the two cmdlets, and when you might look to use one versus the other depending on what you are trying to accomplish.

Thanks you, Marco, for helping to clarify some of the confusion between when to use Write-Host and when to use Write-Output.

The 2011 Scripting Games Wrap-up Week will continue tomorrow when our guest blogger, Bartek Bielawski, talks the 2011 Scripting Games.

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

Add Excellent Comments to Your PowerShell Script

Anonymous — Mon, 16 May 2011 05:00:00 GMT

Summary: Microsoft Scripting Guy, Ed Wilson, shows you how to add excellent comments to your Windows PowerShell script.

Microsoft Scripting Guy, Ed Wilson, is here. Today is a celebration! No, it is not international Scripting Guy Day (that is January 11), rather today is our 1750^th Hey Scripting Guy! blog. If it seems like only a few months ago that we celebrated our 1500^th Hey Scripting Guy! blog (it was September 8, 2010), it is because these milestones are occurring much faster now that I switched to publishing seven days a week and 365 days a year.

Anyway, that is enough preliminaries. I want to talk about something I noticed during the 2011 Scripting Games. One of the hallmarks of good script design is providing useful comments. I have written about using multi-line comments in the past, but I do not think I have written about exactly what one should add in the comments.

Rather than pick on anyone’s script, partly because many scripts in both the advanced and in the beginner categories violated this guideline, I decided to write a script with lots of bogus comments. The ScriptWithLotsOfBogusComments.ps1 appears here.

ScriptWithLotsOfBogusComments.ps1

# First connect to WMI and get information about the bios

# Store the returned bios information into the $b variable

$b = Get-wmiobject win32_bios

# now I need to print out the version

# I get the version by accessing the version property

# from the object stored in the $b variable

$b.version

# I now need to see if the version number is greater than

# 14. To do this, the first thing I do is split the version

# at the dash and store that in a variable called $c

# that will give me an array of two elements. The first

# element contains the word dell and the second the number

# of the version

$c = $b.Version -split "-"

# once i have the array, i want to ensure the version number

# number has no extra spaces in it so i use trim. Trim is a

# method so i have to use () after the call. Because I am

# working with an array and I want the second element, i use

# [] to index into the array. I can also trim at the same time

# I store the resulting value into the $d variable.

$d = $c[1].trim()

# Now I check the version of the bios. First I ensure I have

# an integer by using [int] and then i use the greater than

# operator which is -gt. The action clause of an if statement

# is placed in a script block which consists of two curly

# brackets.
if([int]$d -gt 14) { "The bios is the latest version" }

I know the previous code is a bit difficult to read, but look at it in the Windows PowerShell ISE, as shown in the following image, and you can tell that it is not much better.

During the 2011 Scripting Games, I saw many scripts that were similar to the script above…or worse. If you read all the comments, you will see that they are not bad comments, but they do not tell anything about the script itself. In addition, there is nothing to tell us about the logic that is used—what does it mean when the script states the BIOS is the latest version? How is version 15 determined to be the latest version? What happens when the script runs on a computer that is not a Dell? There is no check for the computer version, nor is there any message other than the one that states the BIOS is the latest version if the version is greater than 15.

So, although the script has massive comments, the comments are basically useless. This makes the script useless as well. As an ITPro, I do not have enough information about the script to be able to use it to ensure that my computers have the correct BIOS installed. This points to several of my best practices regarding comments.

Best practices for comments

1. When commenting a script, do not explain things that anyone who has a moderate knowledge of Windows PowerShell scripting would already know. I know that the Get-WmiObject cmdlet connects to WMI on the target computer, and I know that the Win32_Bios WMI class returns information about the BIOS on a computer. In addition, anyone who has used Windows PowerShell for more than 15 minutes knows what a straightforward value assignment to a variable looks like. Therefore, the comment lines in the following code are useless.

# First connect to WMI and get information about the bios

# Store the returned bios information into the $b variable

$b = Get-wmiobject win32_bios

2. A good comment should explain the logic of the script. If data is returned in a particular format, and it needs grooming prior to use, it is a good practice to explain that logic in a comment. This enables the user of the script to make changes should the format of the data change in the future. In particular, this type of comment will simplify troubleshooting in the future. Unfortunately, in the following code, the comment does not really address the point of why the code is written as it is.

# I now need to see if the version number is greater than

# 14. To do this, the first thing I do is split the version

# at the dash and store that in a variable called $c

# that will give me an array of two elements. The first

# element contains the word dell and the second the number

# of the version

$c = $b.Version -split "-"

# once i have the array, i want to ensure the version number

# number has no extra spaces in it so i use trim. Trim is a

# method so i have to use () after the call. Because I am

# working with an array and I want the second element, i use

# [] to index into the array. I can also trim at the same time

# I store the resulting value into the $d variable.
$d = $c[1].trim()

3. If the script has any type of unique logic or “business rules” in it, these should be explained. In the code that follows the script checks to see if the BIOS version number is greater than 14. If it is, the script displays a message that says, “The BIOS is the latest version.” Unfortunately, the comment does not explain how the number 14 as a baseline value is obtained. Nor does it explain the limitations of the assessment, or the applicability of the results. In fact, the comment for this portion of the code simply states the obvious. In fact, it is worse than that, because it does not explain what the number 14 is doing in the code. I simply assume that the number 14 is a baseline BIOS, but that is not really explained in the comments.

# Now I check the version of the bios. First I ensure I have

# an integer by using [int] and then i use the greater than

# operator which is -gt. The action clause of an if statement

# is placed in a script block which consists of two curly

# brackets.

if([int]$d -gt 14) { "The bios is the latest version" }

So, the script has lots of comments, but those comments ignore the things that should have been commented. In addition, there are so many comments, that they obscure the actual code and make it difficult to read the script.

In the ScriptWithBetterComments.ps1 script that follows, I still have a lot of comments. But I have comments about future work items, and I explain the logic and business rules used in the script. This script is shown here.

ScriptWithBetterComments.ps1

# This script only runs on Dell computers

# TODO add computer maker check to script

# TODO add remote capability

$b = Get-wmiobject win32_bios

$b.version

# The version appears as Dell - 14. I match only

# the number, so I split the number from the string.

# In future, this code might need revision if format changes.

$c = $b.Version -split "-"

$d = $c[1].trim()

# Dell's website states the latest bios version for our

# computers is 14, so this is what we check here.

# TODO remove string literal and use variable.

# TODO produce output when not the latest version.

if([int]$d -gt 14) { "The bios is the latest version" }

# TODO add ability to update bios if not on latest version

In addition to writing better comments, I also placed spaces between the blocks of comments. This makes the code easier to read, as shown in the following image.

That is a quick overview about using comments. 2011 Scripting Games Wrap-up Week will continue tomorrow.

Ed Wilson, Microsoft Scripting Guy

Expert Solution for 2011 Scripting Games Beginner Event 8: Use PowerShell to Write Disk File Information for Excel

Anonymous — Wed, 27 Apr 2011 05:00:00 GMT

Summary : Microsoft PowerShell MVP, Doug Finke, gathers file information and writes it to a CSV file that is readable in Excel while solving 2011 Scripting Games Beginner Event 8. Microsoft Scripting Guy, Ed Wilson, here. Doug Finke is the expert commentator...(read more)

The 2011 Scripting Games Beginner Event 10: Use PowerShell to Measure Time to Complete a Command

Anonymous — Fri, 15 Apr 2011 05:00:00 GMT

Summary : Beginner Event 10 in 2011 Scripting Games uses Windows PowerShell to determine the amount of time a command takes to complete. About this event Division Beginner Date of Event 4/15/2011 12:01 AM Due Date 4/22/2011 12:01 AM Event scenario Your...(read more)

Use PowerShell to Replace Text in Strings

Anonymous — Mon, 21 Mar 2011 05:00:00 GMT

Summary : The Scripting Wife learns how to use Windows PowerShell and regular expressions to replace text in strings. Microsoft Scripting Guy, Ed Wilson, here. I just finished a meeting with the Microsoft TechEd people about doing a series of five Live...(read more)

Filter PowerShell Output with the Out-Gridview Cmdlet

Anonymous — Fri, 25 Feb 2011 06:00:00 GMT

Summary : The Scripting Wife learns how to filter output by using the Windows PowerShell Out-Gridview cmdlet. I am happily anticipating this weekend in Seattle. I leave for Seattle tomorrow evening. I will be participating in a portion of the MVP summit...(read more)

Scripting Wife Learns to View Data with Out-GridView

Anonymous — Thu, 24 Feb 2011 06:00:00 GMT

Summary : The Scripting Wife learns how to view and to sort data by using the Out-GridView Windows PowerShell cmdlet. I just finished with a fun conference call with a colleague in which we were talking about how to best work with the community. Originally...(read more)

Format PowerShell Output with an Easy-to-Use Table

Anonymous — Wed, 23 Feb 2011 06:00:00 GMT

Summary : The Scripting Wife learns how to format Windows PowerShell output with the easy-to-use Format-Table cmdlet. Microsoft Scripting Guy, Ed Wilson, here. I wonder how you might describe the perfect day? For me, it consists of receiving feedback...(read more)

Scripting Wife Learns to Format Wide Output with PowerShell

Anonymous — Tue, 22 Feb 2011 06:00:00 GMT

Summary : The Scripting Wife learns how to use the Format-Wide cmdlet in Windows PowerShell. I imagine winter has nearly departed Charlotte, North Carolina and that spring will arrive soon. Yesterday, besides being rather long, turned out to be gorgeous...(read more)

Scripting Wife Learns about Formatting PowerShell Output

Anonymous — Mon, 21 Feb 2011 06:00:00 GMT

Summary : The Scripting Wife learns from the Microsoft Scripting Guy about formatting Windows PowerShell output with Format-List . It is a Monday morning much like any one of hundreds of previous Mondays. The celestial orb has yet to make an appearance...(read more)