Its great that MS are finally going to give us some powerful command line tools. Its many years over due but Monad looks pretty cool.

They've clearly borrowed a lot from the Unix 'every thing is a file' Model. I like the way the Registry etc. are all mapped to drives under the monad root directory.

But how far do they go with this? Unix has something called the /proc filesystem. Under the /proc directory you'll find sub directories for each currently running process. Under each process directory  there are further directories which list open file handles for that process and cpu usage, memory usage etc. This would be welcome in Monad as well as their get-process command.

The SQL-like querying of the output is definitely something new, with no real equivalent in Unix. This is something that would be very hard with Cygwin or bash. I wonder how all of this will tie in with WinFS? A lot of potential synergies there.

But the biggest innovation could also be a drawback. Everything seems to be an object in the Monad world. The input and the output of all these Cmdlets are objects, which is what allows us to run fancy queries on the output of the Cmdlets.

However this turns Monad into a closed system. Plain Unix is entirely text based, read text from STDIN write text to STDOUT or STDERR. This means that any commandline application could be used in a shell script. So I wonder how flexible Monad will really be?

For example, could I stick an existing network packet sniffing program into an MSH script and do all this funky querying of its output to debug network problems? Or do I have to write a C# Cmdlet wrapper around the exisiting tool before I can run it from my script?

Or could I run sql scripts against my database, and depending on the text output, send an email to the administrator saying the job had failed. Or do I need yet more C# Cmdlets?

The pure simplicity of the text in, text out Unix model made scripting easy, extensible and flexible. For Monad to succeed it will need to be all of those things