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."

Comments

Re:It's about time

[MBCook]

Both of those are BASH (OSX used to use csh or maybe tsh but they switched it). Personally I LOVE BASH. After messing with Linux for a few years, the Windows shell drives me nuts. It's just so primitive feeling.

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?

What's the Point?

[max born]

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, ... what problem is Microsoft proposing to sovle here?

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:I've been using an older version....

[bersl2]

The actual versions of commands seem entirely too object oriented and thus too verbose.

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.

It's not quite all that

[0x0d0a]

Yes, everything's dandy, until you happen to be using two programs that don't export and import data in compatible formats.

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 with program output that wasn't purely text). It didn't catch on. Dunno how many programs could parse said output, though, or whether it was intended for data representation directly to the user.

On the other hand:

a) Microsoft has clearly realized that administrators need a good shell environment and they have not been providing it. This is a Good Thing, and they get points for picking up on this and trying to do something about it. This may be a positive new start. I dunno who started this project, but they clearly weren't blinded by NIH -- people like Linux partly because there's very little NIH associated with it. People like the *IX shell, and Microsoft is responding. Thumbs up on that.

b) Microsoft is clearly doing something with their Microsoft Research people that is actually going into the OS, and trying to push the envelope instead of just copying. (While the Plan 9 thing above is *similar*, this is not just something they bought from someone.) That also is good.

Re:It's not quite all that

[0x0d0a]

You missed the part about the type system, then. Any program can access the data, because the data is packed in nice structured .NET types -- arrays, lists, instances, etc.

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 .NET application author is feeling, an application *might* be able to spit out data that can be understood by a human. It also might just expose data that can't be used worth a damn except by another program.

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.

Re:It's not quite all that

[Chris_Jefferson]

Just because all your programs input / output ASCII, that doesn't make them "compatable formats".

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.