Because I don’t have to administrate any windows-clients during my holidays I didn’t read that many stuff/news related to M$. While searching for some interesting blogs I stumbled across Jason Nadal’s blog covering Monad.
Monad is the codename (from greek philosophy meaning “indivisible unit”/german: Einheit, Unteilbares) for the new command shell msh.exe shipped with Windows Longhorn. Monad is a framework which tries to cover following topics:
* Focused on automation & scripting
* Focused on power users and administrators
* Foundation for Task-Based management
The Longhorn Developer FAQ says:
Managing systems and applications is largely about performing and automating useful administrative tasks. Learn about a revolutionary new task-oriented Automation Framework to generate “commandlets.” Commandlets are surfaced as management APIs, Commands in a Next Generation Command Line Shell, and through GUI tools. See how a small amount of code can be turned into a rich and powerful set of commandlets and provide prescriptive guidance on modeling and naming administrative tasks.
As a zsh lover I really hate the windows command-line shell cmd.exe. Not only the shell and it’s commands itself but also the environment. You can not resize the window dynamically, copy/paste really sucks, no functionallity like GNU screen provides and so on.
So why take a look at MSH? What I find interesting at MSH is the concept of structured object pipelines where objects instead of text flow between commands exists. You should be able to use WinFS filtering through the pipe symbol and export data natively to some well known file formats (out-html, out-excel,…). MSH tries to combine features of unix-shells and WMIC ( Windows Management Instrumentation Command-line) of Windows XP and Server 2003.
Because I don’t have Windows on my boxes for checking out MSH in more detail I’ll quote Philip Rieck:
Think classes passing objects from one to the other, perhaps giving a UI, taking input, or performing actions – all in managed code (.net). Hmm, you say, isn’t that like any application? Yes! One exception only – you string together the classes (called “commandlets”) that will get executed at the command line, passing in attributes for each class, and implicitly giving the order in which to execute them.
get/process | sort “handles” | out/xml
Okay, perhaps not excatly right syntax, but pretty close. What this will do is instantiate an object of the managed class that (with attributes) says it provides the commandlet get/process. It will then call special methods on that class, and pass the output object (in this case an array of System.ProcessInfo objects) to the next object – the one that provides “sort”.
Awesome. simply awesome. The ease of extensibility for us .net developers is great. Option processing and validation is provided by the shell, and not by the commandlet developer. I can’t wait to learn more.
I registered myself for getting a preview of MSH at betaplace.com because version 2 of MSH works with the .net-framework of Windows XP as well as with 2003 and Longhorn. So being back at work I’ll take a closer look at MSH and also Windows Services for UNIX (SFU) 3.5 which I downloaded some days ago.
Some ressources covering Monad/MSH:
* What the hell are Monads?
* Coming Soon to Windows: The Microsoft Shell (MSH) – by Jason Nadal
* Navigating Objects within the Microsoft Shell (MSH) – by Jason Nadal
* Will ‘Longhorn’ allow higher-level thinking? By Peter Coffee
* Monad Session at Bangalore User Group Meeting
* .NET Undocumented: Wesner Moise’s musings on .NET, Technology, Entrepreneurship and Life – Monad Shell
PPT-slides (works fine with ooimpress):
* “Monad Shell – Task-Oriented Automation Framework” by
Jeffrey P. Snover (Management Architect) [WINHEC 2004]
* “Building Manageable Apps: Admin Scripting & Automation” by Jeffrey Snover (Management Architect) [PDC 2003 ]