Slashdot Mirror
Microsoft Releases A New Monad Command Shell Beta
Watercooler Warrior writes "Slashdot originally broke the news that a new Microsoft command shell was in the works when a reader noticed a suspicious job posting by Microsoft India. Today Microsoft released the first really usable version of the shell (codenamed Monad) to beta testers - and anyone who carefully reads the WinHEC slides about Monad will find how to join the beta and get a peek at it. The shell looks like a bunch of old-school Unix and Perl hackers were given free rein to do what they wanted with the .NET framework, and from what is known about the backgrounds of the Monad developers this is probably pretty close to the truth."
Google has a new command shell coming out as well; the name? Gonad.
Quidquid latine dictum sit, altum viditur
First thing I thought when I saw Monad was its definition from category theory. A Monad is a triple, containing a functor, and 2 natural homomorphisms.
Less cryptic, is its use in Haskell as way of parameterizing computations. Specifically its used to produce the I/O Monad which is parameterized by some type A in the pair IO : a -> world -> (a, world).
More in line with ur question, the word Monad comes from greek , and it means "one" "single " or "unique". So I guess they think this is a "unique" bit of work.
And I can't say I'm that impressed yet. I'd like to see man pages or something actually implemented. man currently does stuff but man doesn't work for any command I've tried (thus there don't seem to be *any* options). There's a lot of aliases built-in to emulate Unix (e.g. ls, ps) but the lack of grep makes piping seem...well pointless. The actual versions of commands seem entirely too object oriented and thus too verbose. "get-directory" is not something I want to type (I can't remember off the top of my head, but some of them are really absurd). "ps" is ps for a reason. No frequently used command should be more than 4 letters, or require you to use aliases so you don't end up writing a novel.
Your milaage may vary. I don't care about a scripting language. I have Perl (for Win32). As far as an interactive shell, it still has a lot of rough edges. Personally, I'd rather just use Cygwin/Bash and get a real shell.
(Though I talked to one of the guys personally and he seems pretty cool.)
-- Political fascism requires a Fuhrer.
Go to http://beta.microsoft.com, login with your passport account.
:)
The guest id is mshPDC.
Go nuts.
Check out Mon and Mon.cgi
This is one of those situations where I think MS is doing a serious NIH (Not Invented Here) for no good reason. I can understand the reason to make Direct X instead of use OpenGL (for controll) and other such decisions. But I don't think having their own shell (instead of an implementaion of BASH) does them any good. I don't think it helps them sell more software. I don't think it helps them controll the market more. They should have taken BASH, and extended it with their .NET stuff.
I can use BASH on Linux, BSD, BeOS, OSX, and many many others. Why should I have to learn a new shell for Windows? Why can't they just accept it for once. It doens't cost them anything. If anything it would make porting apps over to Windows from other platforms EASIER.
At least make it so I can replace my shell easily (like you can change your default shell on other platforms)? That would be enough for me.
It's not exactly MS's fault that their current shell isn't very good. They've been going pure GUI and trying to keep people there. They've said DOS is dead and no one should ever have to use a CLI. So they've had no reason (based on that) to improve the shell since it's last incarnation, DOS 6.22. Of course now they are making a new CLI and making a big deal over it. Everything old is new again, eh?
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
Basically, Monad formalizes in .NET the pipe interface between shell programs. A pipe participant is just something that implements the appropriate "commandlet" interface: it receives some input, produces some output, maybe some errors.
However, in the case of Monad the input and output can be anything, not just text. So in the example:
- get-process | where "handlecount -gt 400" | sort handlecount | out-chart processname,handlecount
The get-process command produces a sequence of processes; where filters it based on an attribute; sort sorts on an attribute, and out-chart produces a textual table of the filtered output.It's important that the input and output of these processes are structures (actually, objects, but I don't want to tickle anyone's prejudices about OOP). .NET knows at runtime about the attributes these structures can have, so you can write apps that manipulate a wide variety of object types: files, metadata-annotated documents, log entries, whatever.
Naturally input/output can be pure text, allowing all the traditional Unix commands such as grep.
Immediate benefit? If you have the right translator, there's no need to munge text output using awkward tools like tr, cut, awk and so on, just to get at the process ID column of ps or the URL column of the Apache log file.
This is better than Unix shells.
Illustrated here.
Reminds me of the "Magical Microsoft Moments" story:
I've been attending the USENIX NT and LISA NT (Large Installation Systems Administration for NT) conference in downtown Seattle this week.
One of those magical Microsoft moments(tm) happened yesterday and I thought that I'd share. Non-geeks may not find this funny at all, but those in geekdom (particularly UNIX geekdom) will appreciate it.
Greg Sullivan, a Microsoft product manager (henceforth MPM), was holding forth on a forthcoming product that will provide Unix style scripting and shell services on NT for compatibility and to leverage UNIX expertise that moves to the NT platform. The product suite includes the MKS (Mortise Kern Systems) windowing Korn shell, a windowing PERL, and lots of goodies like awk, sed and grep. It actually fills a nice niche for which other products (like the MKS suite) have either been too highly priced or not well enough integrated.
An older man, probably mid-50s, stands up in the back of the room and asserts that Microsoft could have done better with their choice of Korn shell. He asks if they had considered others that are more compatible with existing UNIX versions of KSH.
The MPM said that the MKS shell was pretty compatible and should be able to run all UNIX scripts.
The questioner again asserted that the MKS shell was not very compatible and didn't do a lot of things right that are defined in the KSH language spec.
The MPM asserted again that the shell was pretty compatible and shouldwork quite well.
This assertion and counter assertion went back and forth for a bit, when another fellow member of the audience announced to the MPM that the questioner was, in fact David Korn of AT&T (now Lucent) Bell Labs--the author of the Korn shell.
Uproarious laughter burst forth from the audience, and it was one of the only times that I have seen a (by then pink cheeked) MPM lost for words or momentarily lacking the usual unflappable confidence.