System administration has always been windows’ Achilles’ heel. The graphical tools that simplify basic chores just get in the way when there’s heavy lifting to be done. And CMD.EXE, the hapless command shell, pales in comparison to the Unix shells that inspired it. Win32 Perl has been my ace in the hole, combining a powerful scripting language with extensions that can wield Windows’ directory, registry, event log, and COM services. But I’ve always thought there should be a better way.
Jeffrey Snover thought so, too. He’s the architect of Monad, aka MSH (Microsoft (Profile, Products, Articles) Shell), the radical new Windows command shell first shown at the Professional Developers Conference last fall.
So, I was delighted to get the chance to give this new tool a try. You don’t need Longhorn, by the way. I’m running MSH on Windows XP (Overview, Articles, Company) with the 2.0 version of the .Net Framework that comes with the Visual Studio 2005 beta. My first reaction? MSH rocks. System administration on Windows, and ultimately everywhere, will be forever changed for the better.
At its core, MSH is an object pipeline. Unix, of course, invented the pipelining concept. But in Unix-like systems - including Linux and OS X - the data that’s passed from one command to the next is weakly structured ASCII text. When you’ve got smart, self-describing objects flowing through that pipeline, it’s a whole new ball game.
Recently, for example, I wrote a typical management script for a Windows 2003 Server. Its job was to filter a subset of running processes by name and then kill any of those exceeding a memory threshold. Using Python in conjunction with Mark Russinovich’s PsTools suite, I did this in the time-honored way: List the processes, split the output into columns, associate the first and third columns with process name and memory use, and then finally identify and kill memory hogs.
Here’s the drill with MSH. You start by typing the command get-process. As does Unix’s ps command, get-process prints a bunch of process statistics on the console. But under the covers, it emits a sequence of System.Diagnostics.Process objects. You can look up that class in the .Net Framework documentation, but it’s easier to just ask an instance of the object to display its methods and properties. If there are too many to view conveniently on the console, pipe the information to an HTML file, a .Net grid control, or an Excel worksheet.
When you’ve identified the properties of interest, it’s trivial to isolate them, filter them, and pipe the filtered subset to the stop-process command. With a pipeline full of .Net objects, it’s all oddly familiar yet dramatically easier.
MSH is quirky, complex, delightful, and utterly addictive. You can, for example, convert objects to and from XML so that programs that don’t natively speak .Net can have a crack at them. There’s SQL-like sorting and grouping. You write ad hoc extensions in a built-in scripting language that feels vaguely Perlish. For more permanent extensions, called cmdlets, you use .Net languages.
With MSH, Windows system administration manages to be both fun and productive. And the story will only improve as the .Net Framework continues to enfold Windows’ management APIs. Competitors take note: Windows is about to convert one of its great weaknesses into a strength.