If you’re testing your PowerShell scripts (manually or automatically,) one of the first questions you’ll end up asking yourself is, “did I test enough?” This is common problem in all of software development. To the rescue is a simple metric known as “Code Coverage” – a measure of how much code you exercised during the testing of that code. However, the measurement is just the end result – you need a tool to get you there.

For a long time, I’ve been thinking about learning to fly. One of the random long-distance-drive conversations I like to have is, “What job would you do if you were for some reason prevented from doing what you do now?” For me, flying has always been something I would entertain, but only romantically. The downsides to doing it professionally are huge – the time away from your family and strict seniority-based promotions being the two largest factors.

A few years ago, we experimented with a “Live” version of Get-ChildItem that retrieved elegant textual context-based advertisements from the internet as you used PowerShell. This has been very successful, but unfortunately, a small subset of our trial user population has experienced crashing behaviour due to these new shell modifications. We have been unable to reproduce the issue in our labs, so the users in question have sent us screen casts of the crash.

BgShell is a proof of concept PowerShell host that explores the idea of PowerShell as a background Macro program.

[Download: http://www.leeholmes.com/projects/SyntaxHighlight/Start-Colourizer.zip] In our most recent CTP, we exposed PowerShell’s parsing and tokenizing API for the great benefit of ISVs and hobbyists alike. As an initial demonstration of it, Show-ColorizedContent let you display nicely formatted code listing in your console: While this is very cool, we can actually push the parsing and tokenizing API even further. How about real time? The first time I got this working, I actually giggled a little with glee.

When O’Reilly put up the overview page for the Windows PowerShell Cookbook, the sample chapter was originally “Looping and Flow Control.” While a useful chapter in its own right, it didn’t really highlight the solution-oriented focus the book takes. They’ve now updated the sample chapter to one much more representative: Environmental Awareness. The goal of this chapter is to help you work with the global environment (environment variables and common system paths,) and script’s environment (its location, name, and invocation info.

A question recently came up asking why the -eq operator doesn’t work for two different (but equal) SecureStrings. By default, almost all environments (the .NET Framework included) test if two things are exactly the same – that they are stored in the same place in memory. This is called reference equality. [D:\documents\WindowsPowerShell] PS:14 > $test = Read-Host -AsSecureString **** [D:\documents\WindowsPowerShell] PS:15 > [Object]::ReferenceEquals($test, $test) True [D:\documents\WindowsPowerShell] PS:16 > $test -eq $test True That’s not usually what people want, so each individual type of object is (optionally) responsible for supporting a value-based equality test.

I’m not particularly a drum fan, but this is an amazing feat of skill and technology. Since I injured my middle left finger playing Guitar Hero 2 way too much when it came out, I’ve been dying to get back to playing it. … so I thought “wouldn’t it be great to be able to play Guitar Hero on the drums?” So I thought about how that might be accomplished… researched, implemented, borrowed, and here I outline the finished product.

The ACoupleOfAdmins blog recently posted a book review of the PowerShell Cookbook (and were kind enough to also write an Amazon Review.) They bring up some excellent points. Mainly, The Windows PowerShell Cookbook will stay on my shelf as a reference book (for the code samples), but I would look to other resources first (e.g. Windows PowerShell In Action by Bruce Payette), if you need a resource to help learn PowerShell.

A question came up on the newsgroup recently about why Exchange changes PowerShell’s execution policy from “Restricted” to “RemoteSigned.” Doesn’t that lower PowerShell’s security? The “Restricted” execution policy isn’t intended to be something that PowerShell users live with forever. It’s a safe default that protects non PowerShell users from being impacted by PowerShell-based malware. For example, many home users had never used VBScript, but still got bitten by the flurry of WSH-based viruses that got mailed to them.