Hey, Scripting Guy! How About a 2010 Scripting Games Recap from One of the Judges?

ScriptingGuy1

 
  Hey, Scripting Guy! How about a brief recap from one of the judges of the 2010 Scripting Games? — SW   Hello SW, Microsoft Scripting Guy Ed Wilson here. I am glad you asked. We have just such a recap from Don Jones, expert commentator and judge for the 2010 Scripting Games. Don, take it away…   The 2010 Scripting Games are over and it was quite a ride! I thoroughly enjoyed my first year as a judge, and I was delighted to see the variety and creativity of the entries. I’ll admit, however, that there are definitely some areas where folks worked a wee bit harder than they needed to, or where a few key concepts went very slightly astray. Adding Help Several of the events awarded style points if you added syntax help to your script, and a lot of you took the bait. I’m a huge fan of being able to use Get-Help to figure out what a function or script is supposed to do, but you may not realize how easy it is to add help in Windows PowerShell 2.0. A good example is this script from the Games: http://2010sg.poshcode.org/code/193.xhtml. This is a pretty solid script; notice how the author has created a function called Get-ScriptHelp? The author even took the time to format the output to look just like Windows PowerShell’s native help. Color me impressed! Unfortunately, all that work was unnecessary in Windows PowerShell 2.0: Just run help about_comment_based_help in the shell itself and you’ll see what I mean. Windows PowerShell can construct and format that great-looking help for you! All you have to do is provide the help information in specially formatted comments. The highly rated entry at http://2010sg.poshcode.org/code/1057.xhtml is a good example of how to do this. Be Silent! And Continue! Unfortunately, that highly rated entry does have one feature that I’m seeing all too often in Windows PowerShell scripts these days: setting $ErrorActionPreference to SilentlyContinue right at the top of the script. That has the effect of suppressing all errors the script might generate, which can make spotting and correcting any bugs a lot harder than it needs to be. The goal behind this is usually to suppress anticipated errors, like trying to connect to a computer by using Get-WmiObject, only to find that the computer is unavailable. What I usually prefer to see is $ErrorActionPreference left at the default of Continue. If you have a cmdlet that you expect may generate an error, use that cmdlet’s -ErrorAction parameter to specify SilentlyContinue for just that cmdlet. By the way, all cmdlets support -ErrorAction (which is aliased as -EA for easier typing); it’s one of the common parameters mentioned in the help. To the author’s credit in that entry (and just to prove I’m not picking on them), they did include some error handling in the way of the Trap construct at the top, which is great news. Should I Process? No? What If… A lot of you went all the way and produced advanced functions for your entries. I call these script cmdlets. Bravo! http://2010sg.poshcode.org/code/418.xhtml is an example of one. I love these because they look, feel, and act just like cmdlets, making them easier for other folks to re-use. There’s that comment-based help again, too! Unfortunately, there are a couple of misunderstandings with these things. One of them relates to the initial CmdletBinding() declaration, right under the comment-based help. Setting SupportsShouldProcess to $True tells the shell that your “cmdlet” supports the -whatif and -confirm parameters. In fact, it’ll add those to your help displays automatically with no work required on your part. I love no work on my part. Unfortunately, declaring support for –whatif and -confirm and is not the same as implementing that support. In order to make -whatif and -confirm actually work, you have to find the bits of your script that change the system—rebooting a computer, changing a registry key, or whatever—and wrap them in a condition statement like this: If ($pscmdlet.ShouldProcess($target) {
# stuff goes here
} The $target variable would contain a description of whatever you were about to modify, such as a computer name or registry key name. When the shell encounters this, it will automatically run the -whatif or -confirm or action if those parameters were used. If your script’s confirm impact (also defined in the CmdletBinding area) is higher than or equal to the shell’s $ConfirmPreference variable, -confirm will be assumed. Remote, Remote, Remote A lot of this year’s events focused on making changes to remote computers. There are two ways to do this: Way number one is illustrated in http://2010sg.poshcode.org/code/418.xhtml around line 176. There is nothing wrong with this technique, which used WMI to connect to a remote computer’s registry provider. Because Windows PowerShell’s registry PSDrive provider doesn’t support mapping a drive to a remote registry, there would seem to be no choice but to use this rather ugly WMI-based registry manipulation. Keep in mind, though, that if you’re willing to make Windows PowerShell 2.0 a requirement on both the local and remote machines (something I hope more and more environments will have in place anyway as they migrate to Windows 7 and Windows Server 2008 R2), you can use Windows PowerShell’s own remoting to send commands to remote computers for local execution. In other words: Invoke-Command -script { mkdir HKCU:SoftwareMyCompany } -computer $computername In that code, $computername contains one or more computer names on which to run the command. Because that command will run locally on each computer, you can use the HKCU: registry drive, and eliminate the need to mess around with other forms of remote connectivity. Y’All Amazed Me You know what? All of these little gripes are really fine details. I expect that most of you would have come across them on your own, given time. I’m truly impressed by the quality and level of the entries I saw, in both the Advanced and Beginner events. I feel more confident than ever that Windows PowerShell is making a positive impact on the world and will continue to do so. If you’d like to continue picking up tips, tricks, and techniques, you’re in the right place. The Scripting Guys have been doling out the goods for what seems like a decade or so. You can also check out my new Windows PowerShell with a Purpose Blog, or check out my Windows PowerShell column in TechNet Magazine at http://technetmagazine.com. See you online! Don Jones
Senior Partner and Principal Technologist, Concentrated Technology   SW, that is the scoop from Don Jones. Guest Blogger Week will continue tomorrow. If you want to know exactly what we will be looking at tomorrow, follow us on Twitter or Facebook. If you have any questions, send e-mail to us at scripter@microsoft.com or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace. Ed Wilson and Craig Liebendorfer, Scripting Guys

ScriptingGuy1

Follow