Slashdot Log In
Microsoft Releases A New Monad Command Shell Beta
Posted by
timothy
on Mon Sep 20, 2004 09:32 PM
from the sneer-or-consider dept.
from the sneer-or-consider dept.
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."
Related Stories
[+]
IT: Microsoft PowerShell RC1 548 comments
rst+ack writes "Microsoft has released RC1 version of PowerShell the .NET-based shell with perl-like syntax previously known as Monad or MSH. PowerShell (PS) has been covered a few times on Slashdot. Contrary to cmd.exe and Unix/Linux shells it operates on objects, not text when passing data between scripts and executables. Easy access to .NET classes allows users to create quite advanced solutions in short time. PS won't be shipped with Vista or Windows Server 2007 but it will debut with Exchange 12."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Google (Score:5, Funny)
Re:Google (Score:5, Funny)
Parent
Re:Google (Score:5, Funny)
Parent
Re:Google (Score:2)
It's about time (Score:3, Interesting)
The current command shell just plain sucks when compared to OSX's or KDE's shells.
I can't wait to install.
truth={ moz: "sweet" }
Re:It's about time (Score:2)
Re:It's about time (Score:5, Insightful)
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?
Parent
Re:It's about time (Score:2)
Re:It's about time (Score:2)
You betcha! Just look at Apple and OSX. I can't really claim this idea as my own (I think someone talked about it in MacWorld), but it is true. The author said how the older Mac OS didn't even have a command line. The big feature of the Mac was that you didn't need commands and could use a menu driven interface. Now one of the big selling points of OS X (for me anyway) is that it has a UNIX base and I can use all the *nix commands and apps that are pretty standard for
Re:It's about time (Score:2)
So it's quite different.
I didn't actually try it, because I don't want to sign up for beta etc, but when it's out, I'll definitely give it a shot.
Re:It's about time (Score:2)
Re:It's about time (Score:2)
Well there is no ctrl-ins or shift-ins but there is a better way to copy & paste using the mouse. Select text using the left mouse button, right click to stop selecting & copy the text into the buffer and then finally right click to paste.
Re:It's about time (Score:2)
Page-up/down for directory history is worth it alone.
--
Tobacco represents a huge tax base for the government. The government is as addicted to the revenue from smokers as the smokers are to the cigarettes.
- WetKarma (plastic.com)
Re:It's about time (Score:2, Insightful)
So would all geeks who use Windows. WinFS gets a lot of hype, but it is Monad
that will drive the next batch of upgrades for Microsoft, especially in server
space. A good command shell is a killer feature.
I remember an online poll in about 1999 or 2000, asking what effect Linux would
have on Microsoft. "Force them to change radically" was the option I voted
for. Monad is the sort of thing I meant. A good command shell is one of the
strengths of most POSIX
I've been using an older version.... (Score:5, Interesting)
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.)
Re:I've been using an older version.... (Score:5, Insightful)
I can't imagine anybody who has ever used a CLI object-orienting it. Did some marketing drone get a say in the design.
The command line is more likely to be used for quick-and-dirty jobs, but the language involved (Bourne, C shell, etc...) can scale up to a larger, more maintainable project. The same can't be said about most object-oriented languages in the downward direction. Of course, maybe I just haven't seen the right ones.
Parent
Re:I've been using an older version.... (Score:3, Insightful)
If the right objects are already made and easy to use, then OOP is great for programming. If you have to worry about designing an object hierarchy when what you really want is a result, then it's a chore.
Re:I've been using an older version.... (Score:2)
Not bad... (Score:3, Funny)
The way it handles pipes is good - but FOR THE LOVE OF ALL THAT IS HOLLY! GET. RID. OF. THE. PAPERCLIP!
(it looks like your writing a shell script)
Re:Not bad... (Score:2)
You're"
Well it's a good thing you came along and corrected his mistake. His post didn't originally make any sense!
This begs the question... (Score:4, Funny)
Re:This begs the question... (Score:2, Insightful)
Re:This begs the question... (Score:2)
If they also implemented highly effective remote command line administration and took a few other pages from places where *NIX design makes life easy for admins I would also be very pleased. And those old school hackers wo
NO, IT DOESN'T (Score:2)
beg the question [yaelf.com]
to beg the question - definition by dict.die.net [die.net]
How to (and how not to) Beg the Question. From "On Language: Semantitheft," by William Safire. The New York Times, May 13, 2001 [claremontmckenna.edu]
Access for Monad Beta (Score:4, Informative)
The guest id is mshPDC.
Go nuts.
Re:Access for Monad Beta (Score:2)
...and if that particular dusty corner of our souls hasn't been sold to the beast yet, and we don't have passport accounts, then... that's it? Can't sign in?
Oh well, scratch that.
Re:Access for Monad Beta (Score:2)
Re:Access for Monad Beta (Score:2)
What's the Point? (Score:4, Insightful)
There's already a plethora of shells out there, -- korn, bash, csh, zsh, and way more. And combined with ultilies like find, sed, grep, awk and with the added availablity of languages like perl, python, 'c' and all the lexical mulitude of routines that go with,
Microsoft should consider cooperating and improving what's already out there instead going it alone and reinventing the wheel. Unless, of course, all those old school Unix developers were really all wrong and now Microsoft's is taking the opportunity to show us how it's really done.
Re:What's the Point? (Score:3, Insightful)
Anyway, what's the problem? It's not written in stone anywhere that thou shalt use the one true scripting method, and who knows if there's a better way unless people try different things? Even if it sucks we have Cygwin already, so people can use any Unix shell that makes them more productive.
This is pretty clever (Score:5, Interesting)
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.
It's not quite all that (Score:3, Insightful)
In the *IX world, stuff moves around in simple text formats. You can glue *any* two programs together, even if the original author didn't intend that you do so.
In the Microsoft world (well, the new Microsoft world), you can glue together programs that are designed to be glued together.
Note that Plan 9 did some similar stuff to this (IIRC there was a project called xmlterm that deal
Re:It's not quite all that (Score:2)
Re:It's not quite all that (Score:4, Informative)
- Yes, everything's dandy, until you happen to be using two programs that don't export and import data in compatible formats.
You missed the part about the type system, then. Any program can access the data, because the data is packed in nice structuredFor example, if something wants to sort objects on an attribute "name", it doesn't need to know the type of the input: it just asks for the value of the name properties. Obviously a sorter needs to know how to compare values against each other: it needs, in short, to be able to turn anything into a string. Those things are solved using formal interfaces: if your "name" attribute is not a string object, it needs to support an interface that allows it to be turned into a string on command (just like Python's __str__(), Java's toString(), etc.). With .NET's type system and automatic boxing/unboxing you already have a rich set of types to interact with.
The challenge here is agreeing on a set of interfaces that make programs able to interact beyond the basic .NET primitives. For example, let's say the output of my program consists of image bitmaps. Something like a class with an (x, y) extent and a vector of RGB objects. All you need to share such objects is to specify the appropriate interface for clients to use. The client certainly doesn't need any of the originator program's code, just the interface.
If you think about it, such interfaces already exist in daily usage in a different format: JPEG. GIF. PNG. They're standards need for interoperability. In the same way, programs need to standardize their exchange mechanisms, and if you're saying that the solution is for "everything to be just text" (or more precisely, octet streams) then you're just moving the problem somewhere else. Ultimate, at some point that text/those octets need to become something else.
(By the way, I'm not a .NET developer.)
Parent
Eh? (Score:2, Informative)
I'm sorry, but those are not equivalent statements at all. In most (decent) languages, you implement a sort order simply by providing an arbitrary function (or class, or object, or closure, or whatever) that compares two objects. Hardly ever do you need to convert them to strings.
Not to mention that even string sorting is done this way-- you don't sort strings in the
Re:It's not quite all that (Score:4, Insightful)
Sure, but all data structures in C are made of C primitives. That doesn't ensure that two programs can interoperate. The Windows Registry contains structured data. UNIX config files contain text. I can read almost every UNIX config file with little trouble (though I might need to look up what an option is to get precise data about it). The text files are intended to be read by people -- the config format is thus self-documenting. The Windows Registry is intended for programs to talk to programs. The interface *might* be human-readable but often devolves into cryptic encodings jammed into strings that aren't documented anywhere -- the interface is not self-documenting.
The same thing goes for *IX programs. You have a mass of programs that spit out human-readable text output. A self-documenting format, one intended to be read by humans. Now, depending on how benevolent the
Now, I agree that the idea of data pipelines of more complex data can be useful. Frankly, I like the idea of even-more-powerful graph programming languages, as certain data-processing environments sometimes use -- image-processing, audio-processing. However, I've rather more dubious when it comes to general-purpose pipelines.
Also, think about the social issues. *IX world -- do the bare minimum to be usable by a human, and your program is interfaced with. Microsoft world -- you need to go above and beyond.
And the roles that data pipeline programs play. *IX world -- data pipelines are generally quick 'n dirty tools. They let you write custom and personal tools in a snap. If you want to interface functionality, you use full-blown libraries, with an API that isn't limited by the structure of a pipeline. Microsoft world -- new program structure for introducing a limited interface between programs, intended for more serious programming.
Parent
Re:It's not quite all that (Score:4, Insightful)
I've got bitten more than once by filenames with spaces in, and always thought it would be nice if there was more structure to the input and outputs. Once I got badly bitten by some joker who decided to make a file called "-rf" (yes, you can make such a file). This kind of system with more structure makes it much easier to seperate filenames, switches, etc. in a clean and safe manner. I'm quite looking forward to it myself.
Parent
Re:It's not quite all that (Score:2)
#!/bin/gawk -f
# bashescape.awk
{
gsub(/\\/, "\\\\");
gsub(/
gsub(/!/, "\\!");
gsub(/"/, "\\\"");
gsub(/'/, "\\'");
gsub(/:/, "\\:");
gsub(/;/, "\\;");
gsub(/=/, "\\=");
gsub(/?/, "\\?");
gsub(/@/, "\\@");
gsub(/\^/, "\\^");
gsub(/{/, "\\{");
gsub(/}/, "\\}");
print;
}
#!/bin/bash
# myxargs
bashescape.awk|xargs "$@"
The problem is that xargs isn't a shell builtin, so it doesn't really know what the characters you need
Re:It's not quite all that (Score:2)
In which case, you'd probably use one of their generic tools to remap attributes, or you could always whip up a quick
Certainly in some cases a plain text pipe is more convenient, but being able to pass structured objects around in a pipeline has the capability to deliver even more; and, especially with regar
Re:This is pretty clever (Score:2)
I think similar results can be achieved using DCOP/KDE or the GNOME equivalent, probably KDE , GNOME hackers can comment on that.
Re:This is pretty clever (Score:2)
The Unix world could use this
What? Copying Windows? I thought we already were...
Excellect win32 shells exist, but... (Score:2)
Is this related to one of those magical moments? (Score:4, Funny)
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.
Msh misses the point (Score:4, Interesting)
However MSH seems (with its OO-influenced design) to be a bit too complex for ordinary work. If people dont use it for ordinary work, they cant write scripts "for free".
The problem today isnt that Windows cant be scripted - it can via VBScript.
UNIX shells are constructed the way they are because users should BOTH use them for scripting, and for every other task. M$ compromises with simplicity (with its OO-design), so MSH will never be as productive as, for example tcsh.
Is it just me... (Score:4, Interesting)
Think about it. Over the past few years, the windowing environments in Linux have grown more and more advanced. With the newer XOrg releases and upcoming KDE4 and Gnome 3, I expect amazing things from the Linux desktop.
Meanwhile, while Linux has been addressing it's core weakness, Microsoft already has a firm foothold on the desktop. Instead, the past few years they have been integrating more and more sysadmin-friendly technologies - such as integrating scripting into the OS, improving their command shell (and replacing it - hence Monad), improving remote administration.
Windows has WinFS, Linux has Reiser4 + plugins.
In the next few years, I doubt a layman will be able to tell Windows and Linux apart from a purely features / technology perspective. What *ill*be important, is he thing that is the most important - who do you trust with the source code to your OS? A private company or a group of hackers.
Monad is the code name ... (Score:2, Funny)
(old joke, felt the need to revive it!)
It's about time! (Score:2, Funny)
My computer experience started with MS-DOS 3.3. I became pretty good at writing batch files.
I loved DOS and resisted Windows at first. As we all have since learned, resistance is futile and I was assimilated.
Then, I discovered *nix and I saw the light... a powerful operating system with a command line. I've never looked back.
My colleagues and friends all think I'm fully Anti-Microsoft, but I just prefer to seek alternatives to Microsoft's overpriced products.
If this command shell becomes a truly
Re:Monad == ?? (Score:5, Informative)
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.
Parent
Re:Monad == ?? (Score:2)
Re:Monad == Best_Name_Ever (Score:2)