PowerShell is a “revolutionary new interactive shell”. I heard about this two years ago at MTS05, so I’m not terribly interested in it, but last time Bill Hillf gave the demo, not the Program Manager as in this case.
He covered the basics up-front, like how PowerShell (formerly Monad) is a managed app that can be used to include the .NET libraries into your shell scripts, how you can pipe objects in addition to text streams together, and so forth.
Jim emphasized that you can continue to use your existing Windows shell scripts with no changes in the environment and that the the on-line docs have a ton of ready-to-use examples.
He talked about the need for shell scripts to accommodate organic growth: sys admins need to put out a fire and it grows from there. (As an aside, he said his slide deck was built with a PowerShell script; he likes to automate everything.)
In the demos, Jim showed off its “rich aliasing capability” to support ls, ps, and other Unix commands. Jim came to Microsoft when they acquired his Unix-on-the-WinNT-Kernel company so he prefers the Unix way.
Because PowerShell is object-oriented, its built-in commands (called “cmdlets”) return objects. So when you type a command that lists services, they are displayed as a textual list of services because PowerShell’s built-in logic decides to display those objects as a text line. You can easily render the objects in custom ways, and of course wire the objects together with other commands to do really interesting things.
He demoed listing all the running services as text, as a detailed list, as an HTML table, as HTML, etc., all by passing the results of a “get-services” command through various additional commands.
Its got a built-in type coercion system that converts console text into the type expected by a command. You can’t extend its built-in type coercion routines for built-in .NET types, but you can create your own type converters for custom types.
They use $_ from Perl to represent the current object that is being inspected, such as:
ps | where { $_.handles -gt 1000 }
Which says list the processes where the handles is greater than 1000. Here’s the next step:
ps | where { $_.handles -gt 1000 } | ft processname, company
Which displays the processes with only two columns: processname and company. This example shows the power of matching against object properties as a simple grep would be less than useful given that there are a ton of numbers in the output — but I could have reduced the output to just the handles column and done a grep.
So I asked him if in his experience doing matching based on object properties is generally useful as opposed to the simplicity of the grep approach. He claimed that it absolutely has been a huge advantage as he’s written thousands of his own scripts. He showed off a number of ways in which matching against object properties is a big win. He moved so fast I couldn’t really write down all the stuff he showed, but it was very cool.
An audience member asked, “How big is this thing?” It turns out its huge. The footprint of the PowerShell process he showed us was somewhere between 45-121 MB (I don’t know how to read the memory output and neither did he). Bash of course is a small, small fraction of this.
You can assign any object to an environment variable and manipulate the object subsequently. He demoed this syntax:
$a = get-ipconfig
$a[0].hostname
which stores the object returned by get-ipconfig into the variable and then gets the hostname off the first interface configuration object. Sweeeet. He riffed off this example by storing the results of ps into a variable and then interrogating the resulting objects for all kinds of info on the processes.
You can serialize/deserialize objects into XML for use across sessions, but the serializer only goes two levels deep and will of course punt on non-serializable fields. You can’t send live objects across PowerShell sessions.
Another neat trick:
foreach ( $i in ls ) { "{0,8} {1}" -f $i.length,$i.name }
This shows a list of files with the size next to the name of the file.
Q: Will sysadmins really be able to use all this stuff? Who’s the target market?
This is for the advanced Unix system administrator who has to do Windows and Unix and used to say, “Man, I wish I could do in Windows what I can do in Unix.” Now I want them to say, “Man, I wish I could do in Unix what I can do with PowerShell on Windows.” The next version of PowerShell will target making it easier for the novice script (through wizards, etc.) — ideas still up in the air on this one.
PowerShell is available for download and will be part of the Longhorn Server release.
Q: Wouldn’t PowerShell be an ideal open-source project?
We are seriously considering that. We’ve had 400,000 downloads of PowerShell since we released it; its capturing the imagination of scripters on Windows.
Q: Can I run this on Mono?
We don’t release the source, and it requires 2.0, and I don’t think that Mono supports 2.0.
Ben Galbraith 