Tuesday, April 13, 2004

MSH Just Gets Cooler!

I've written about Microsoft's new command shell, MSH, in the past, but as it evolves, it just gets cooler!

MSH is an all new approach (from Microsoft!) to a command shell. MSH (Monad Command Shell) combines the very best of the key command shell concepts from Unix (e.g. the pipeline, proper control structures, variables, etc.) with .NET (objects with meta-data and evidence). Microsoft demonstrated this at PDC last October, and provided a first look. Google for the impressions - I know I was excited!

Since then, a lot of good thinking, and development, has been done and MS have released an updated version of MSH to testers. I've been playing with it bit and I'm blown away. It needed an update to the .NET Framework. But most surprisingly, I was able to remove the earlier PDC version of the .NET framework, and deploy the updated version flawlessly - and without a reboot.

The first think I noticed is that the syntax has changed in one big way. In the PDC version, cmdlets and verbs were separated by the "\" character. It's been changed to the "-" character. At first sight, this looks strange. I guess I've always seen the "\" as a separator while "-" is not - in my COBOL days, variables like process-get would have been just fine. I guess I'll have to get used to that!

I continue to be impressed at the very clean and slick architecture of both the cmdlet and the cmdlet provider. Cmdlets, the heart of MSH, are little programs that do useful things. They take input, and create output - via the MSH pipeline (or stdin/stdout). Cmdlets provide both a great development environment and to provide consistent user experience.

The Cmdlet provider architecture take this one step further. Cmdlet Providers expose a set of base classes to the MSH Provider architecture. This architecture includes standard cmdlets that act on the classed exposed via a provider. Each cmdlet provider offers a consistent name space that can be navigated by a huge number of standard cmdlets.

If this sounds Greek, think in terms of there key cmdlet providers: the registry, the file system and the active directory. With these cmdlet providers you can obtain information about the components of these data stores in a consistent way. For example, you can type 'DIR' in the context of any of these providers and get a list of their children (OUs in AD, keys in the registry, and files/folders in the file system providers).

So what you ask? Well, with the registry provider, you could write a script to open an OU in the AD, get all the children (e.g. computers, users, etc.) and use the properties of those objects to perform some administrative function. You could do a bulk password reset, for example.

Cmdlets take as input .NET Objects and produce objects. Thus a cmdlet can use the .NET Framework to access the objects consumed and produced. The cmdlet can obtain all the necessary meta-data about the object, which sure beats the prayer-based parsing you used to have to do.

One very neat aspect of the latest version of MSH is the win32-to-ShellObject.msh script. This cmdlet takes 2 arguments: a command and a hash table consisting of a regex production rule to find objects and a set of regex produce rules to find the properties of those objects. This enbles the cmdlet how to parse the output of the command. For example, this is a sample script shipped by Microsoft to handle the ipconfig command:

# Copyright (C) Microsoft Corporation, 2003
# Project: Monad Shell
# File: get-ipconfig.msh
# Contents: Convert the output of ipconfig.exe to MshObject
# History: 20-March-2004 kumarp Created
# the template for ipconfig output that covers both the no-arg case and /all case
$rxIpAddress = '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+';

$ipconfigTemplate =
@{ 'ObjectHeader' => '^([^ \t][^:]+):$';
'Fields' => ( @{ 'Pattern' => "^ Subnet Mask (`. )+: (?$rxIpAddress)" },

@{ 'Pattern' => "^ (Autoconfiguration )?IP Address(`. )+: (?$rxIpAddress)" },
@{ 'Pattern' => "^ DNS Servers (`. )+: ?(?($rxIpAddress)?)";
'Type' => 'string';
'Array' => 1;
'MultiLine' => 1;
'Name' => 'DNSServers';
'MLPatterns' => ( "^[ ]+(?$rxIpAddress)" );
@{ 'Pattern' => "^ Default Gateway (`. )+: ?(?($rxIpAddress)?)" },
@{ 'Pattern' => "^ DHCP Server (`. )+: ?(?($rxIpAddress)?)" },
@{ 'Pattern' => "^ Primary WINS Server (`. )+: ?(?($rxIpAddress)?)" },
@{ 'Pattern' => "^ Secondary WINS Server (`. )+: ?(?($rxIpAddress)?)" },
@{ 'Pattern' => '^ Connection-specific DNS Suffix (`. )+: ?(?([a-z\.]+)?)' },
@{ 'Pattern' => '^ Description (`. )+: ?(?[^\n]+)' },
@{ 'Pattern' => '^ Physical Address(`. )+: ?(?[^\n]+)' },
@{ 'Pattern' => '^ DHCP Enabled(`. )+: ?(?[^\n]+)' },
@{ 'Pattern' => '^ Autoconfiguration Enabled (`. )+: ?(?[^\n]+)' },
@{ 'Pattern' => '^ NetBIOS over Tcpip(`. )+: ?(?[^\n]+)' },
@{ 'Pattern' => '^ Lease Obtained(`. )+: ?(?[^\n]+)' },
@{ 'Pattern' => '^ Lease Expires (`. )+: ?(?[^\n]+) }' }

call-command win32-to-ShellObject.msh 'ipconfig.exe /all' $ipconfigTemplate;

The regular expression, stored in $ipconfigTemplate, tells the cmdlet how to parse the output of ipconfig /all, and how to package that into an object for later in the pipeline.


MSH seems to me to combine the very best from the Unix world, with the rigour of .NET. Microsoft really, really, really should consider delivering this before Longhorn ships! I can see three reasons for shipping early:

1. It helps in the battle against Linux/Unix. It's just one less argument against Windows - we now have the most powerful shell approach in the world, based on .NET. If you get the inside techies excited about .NET the rest will follow.

2. It really helps in the migration. Yes, SFU is cool, but it needs to be rolled out, and requires (yet another) another service to run. I'd like to see migration to an all-Windows environment as quickly as possible.

3. It provides a consistent way of doing all administration. Consistency is something that most administrators like, love, and sometimes find missing.

MSH is cool...

No comments: