For a little less than a week now, I have been playing with the March build of the new command shell that Microsoft will be releasing in the Longhorn time frame. Being a command line/console enthusiast, I find this rather exciting news. Indeed it has been years since MS actually did anything significant to better its command shell – Monad is it.

I don’t really know how much I am allowed to talk about Monad itself because of some NDA material, but if you look around on the net you will find a pretty much a lot. One thing about the way the NDA was explained to me recently was that they said – if you can find the material on the web then assume its not under NDA !! (whatever .. )

One thing that Monad does differently from other command shells, be it cmd.exe or bash/ksh/csh is that Monad is centered around the idea of an object pipeline. Let me explain:

Traditionally one of the ways of defining a console application is to say that it is an application that was access to three streams by default – usually numbered 0,1 and 2 and called the stdin, stdout and stderr. These are text streams. This means that you can read/write text data from these streams.

When you pipe the output of one program to another program on the command line, what you are basically doing is that you are ‘connecting’ the stdout of the first process to the stdin of the second process. So text that it is outputted from one process is treated as input text for the next process. This is known territory.

For a long time I appreciated the beauty and simplicity of this approach – what could be better, well Monad could be.

Monad provides ‘applications’ (I use this term loosely here) on the shell with three streams – but these are not text streams but object streams. Applications that read and write objects in the object pipeline are not traditional processes but are called ‘commandlets’. A cmdlet is actually just a .Net class that is decorated by certain attributes (etc etc).

When cmdlets are executed from the msh command line, these classes are instantiated and are given access to the object streams. So one cmdlet writes objects to the output object stream which is read in through the input object stream of the other commandlet. In essence the same idea of piping as with text streams, but this time what passes around are full blown .Net objects.

Giving this idea a little thought, you will realize that this makes for much richer shell programming. Like for example a lot of time effort is spent in shell programming (traditionally a unix forte) is scrapping out meaningful values from the output of other commands. Even entire languages (awk) have been created largely for this kind of text scrapping. For example if you do a ps –ax, then you really need to cut out (literally) the columns of text where the process id falls so that you can automatically call a kill command with it.

This kind of difficulty completely disappears with Monad simply because the cmdlets down the object stream get full objects and so they can examine the fields of these objects for the parameters they want.

Of course this kind of functionality would have been near impossible in the pre .Net era because there was no understandable concept of a ‘type’ that was applicable across languages. The shell being purely a .Net shell the command-lets can talk .Net and can thus consume any .net type. (Remember this is one of the basic tenets of the .Net platform - that its tries to provide a level playing field for languages to interact).

When a command let returns a set of types and there are no more command lets in the pipeline to consume to objects then the objects are formatted in some standard way to the console. What that means is that if we have a command called ‘ps’ it would be expected to return a collection of objects each of which represent a running process. Now if at the console I type simply

> ps

then there are no more commandlets that receive the process objects returned by ‘ps’. These objects are formatted in a standard manner to the console so that user can see them. Nice?

Monad has really appealed to me in the short time I have spent with it. Traditional shells like bash may have some catching up to do in the light of power like this. Of course Monad is presently at a nascent stage. However for an early pre-beta, Monad is already a very sophisticated and elegant system.

I don’t know if I have crashed any NDAs already. I need to check up on that before I continue.

Next:
Cmdlet parameter binding in Monad 

Other:
Some of my ranting about NDA

Clarifications on NDA related issues about Monad
Pooja on deployment of Monad on 'unsupported' OSes