Microsoft's new CLI 688
An anonymous reader writes "Months ago a story ran regarding a job advert at Microsoft for a developer role to lead the work on a new generation of command line interface.
It has now been disclosed at the PDC and its name is MSH (Microsoft SHell), codenamed MONAD.
Here is the best description so far."
hah. (Score:3, Insightful)
Seriously, this is a wonderful thing. The shell has been one of the most lacking areas under Windows. I don't know how many times I've dropped into Cygwin or, before that, wasted time writing little C apps just to do basic bulk renaming operations and the likes.
Any word on whether they'll standardize the environment across all Windows products, or is this likely to be a server product only? Will this be the standard shell replacement, or will we now have command.com, cmd.exe and newthing.exe all living in parallel? I like choices, but Windows apps' ad hoc use of largeley-incompatible command.com and cmd.exe is already a source of pain.
Re:Very Nice (Score:5, Insightful)
This is going to be for headless servers. So you can ssh into a box and administer it remotely, or through a dumb terminal on a serial port, etc, etc..
There's no good reason your mailserver or each machine in your SQL Server farm needs a GUI.
Re:Very Nice (Score:5, Insightful)
What if Longhorn does indeed provide more security, not only in default settings, but more inherently in the OpenSource?
Do you think the average developer/manager at MS is dumber than your average OS participant? (This is not a tric.. Damn, I'm falling in myself..)
But really - if "we" are to compete, we will have to steal the ideas that "work" from MS camp, just as they're "stealing" "our" ideas that WORK.
Linux is narrowing the gap to MS on the desktop (albeit slowly), and MS is narrowing the gap to Unix on eg. CLI, stability and security. Their software matures too, you know..
And then there's Apple. They make fun stuff. The are not afraid to invent, and they have the money to launch stuff that the OpenSource movement cannot. I don't quite know where to place them compared to OpenSource and MS.
Monad = Ultimate? (Score:2, Insightful)
Z
Re:This made me laugh .... (Score:3, Insightful)
Re:Very Nice (Score:5, Insightful)
Re:What about bash under Cygwin? (Score:1, Insightful)
Consider ESR's tract on "how Unix Happened"; one
of his major (and correct) points is that you
should code a program NOT to talk to programs
that you already have, but to compatibly talk
to programs that HAVE NOT YET BEEN INVENTED.
In short, the coding to use a view (html, XML,
be back-compatible; that trick never works.
Multiple views now means that view maintenance
is now a N^2 problem to keep updating
your view translations as your programs evolve.
If a view translation falls behind, you now have
a big hole and your "shell" no longer does
what you need to do.
The _correct_ (and that is both an ideological
and engineering "correct") is to code the view
so that programs NOT YET CONCEIVED OF will still
be able to interoperate.
Axiom: piping anything but a single data format
is a bad idea.
Theorem: that lowest-level rep needs to be
compatible with simple programs and scripting
languages.
Conclusion: Monad's "type aware" piping is
a _bad_ idea.
passing objects (Score:3, Insightful)
Re:The difference: (Score:2, Insightful)
as for a scripting language that is "objectish" - the closest thing isnt perl, its python...
Re:so, when will we see GNU's version (Score:5, Insightful)
The more microsoft morphs to become like linux, the less people will be inclined to throw away their money when they can get better functionality for free.
Re:The difference: (Score:1, Insightful)
And I'm not sure why this is really being debated, because, while I'm sure there are some Windows users who would be capable of effectively using this, the majority of them won't have a clue and won't bother. They complain about the command line now. Try adding all sorts of options that they'll have to remember.
While this sounds like a cool idea, I predict it will fade into the woodwork eventually.
Re:The Best of All Possible Worlds (Score:5, Insightful)
Monads were, essentially, philosiphical atoms or molecules, albiet in a very metaphysical sense.
=Shreak
Re:so, when will we see GNU's version (Score:4, Insightful)
Re:Very Nice (Score:3, Insightful)
And you get rated 'Insightful' for stating what MS zealots hope.
What if this shell actually knocks the socks off *sh?
Lets be realistic, shall we? First of all, we're talking about what is essentially vaporware - things like "what if it
What if Longhorn does indeed provide more security, not only in default settings, but more inherently in the OpenSource?
Again, more vapour. And (again) what's MS's track record WRT security? I think the phrase "I'll believe it when I see it" sums this up appropriately.
Re:Very Nice (Score:5, Insightful)
No, you get rated insightful for noting what MS has done in the past, and extrapolating the future of their next products based on that.
What if this shell actually knocks the socks off *sh?
That would be nice.
Keep in mind that this isn't a contest. MS has some very nice features burried in their software, and that's great. If MS Windows is ever a better platform choice than the free operating systems out there, I say great!
Woefully, it will still not be the platform I use. Why? Because I require the ability to fix bugs, apply patches on my own timetable (sometimes so fast that my vendor doesn't even know about them yet), and generally control my systems behavior.
Windows does not give me that.
What if Longhorn does indeed provide more security, not only in default settings, but more inherently in the OpenSource?
Security is not a "thing", it's a process. You don't ship your OS in a box with a "NOW WITH 20% MORE SECURITY" sticker and get more security. Longhorn's security will be poor as long as Microsoft continues to deprioritize it in favor of market share. I see no evidence that that has changed since the days of NT4.
Do you think the average developer/manager at MS is dumber than your average OS participant?
No, of course not. The problem is that the average MS employee is working on what a mid-level manager decided he would be working on, based on a company directive from on high that is motivated mostly by marketting. The reason Open Source software tends to be so much more USEFUL, even when it lacks many seemingly obvious features, is the fact that it's created, maintained and refined by those who need it the most. Shells don't seem all that well designed to developers and manageres... and that's because they're not for developers and managers. They're primarily use by sysadmins. A developer spends most of their time in an editor and/or using a rule-based system like make. The shell is just a tool for odd jobs, and many IDEs and feature-laden editors like emacs and vim pretty much suplant the need to use the shell 90% of the time. Sysadmins do not have that luxury.
Look at the MS shell. It is clearly being designed by developers for developers. The ability to manage excel data from the shell is not something that targets the needs of anyone who will have to use this shell routinely. Why is it there? That sort of thing scares me right off the bat, and tells me that this is not a sysadmin tool. Developers under Windows already have very nice tools in their IDEs to script all sorts of interaction with every part of the system that they need. Managers and desktop workers will never want/need a shell.
So ask yourself, which will be more useful: cygwin's bash port to Windows or msh? I can ssh into my Windows box and do admin today, and it requires no msh at all. Why do I need this beast?
But really - if "we" are to compete, we will have to steal the ideas that "work" from MS camp, just as they're "stealing" "our" ideas that WORK.
No, you don't have to steal anything. First off, let's disabuse ourselves of the notion that anything in a shell is new. Shells have existed for decades that do everything msh is (so far) claiming to do. Most of them died a quick death for lack of use.
Next, the most valuable thing that MS has done in the last few years is to put pressure on other OSes to use features that were long available. For example, MS had a journaling fileysystem. Journaling was not new, it was just kind of hard to get right, and all of the implementations out there were fairly speical purpose or closed source. When MS demonstrated that an end-user OS could indeed benefit from having such a feature, dozens of porojects sprang up to take this long-implemented wheel and re-invent it for open source oses.
This sort of "test environment in the large" is very valuable, and MS has alway
Re:Very Nice (Score:3, Insightful)
Because Bill thought that VMS with a GUI would be better, and he doesn't want to lose face now.
Re:Much of this could be done in linux... (Score:3, Insightful)
First- on OS X and Linux, I use psh. I love having a real language as my shell, no need to write little glueish C programs or look up really (more than perl sometimes!) obscure bash syntax. As far as Unix shells go, it's definately top shelf.
But I don't think it could trump MSH- unless we were talking about Perl.NET running psh on Windows or under other OSes using Mono. MSH has some serious strengths- like having access to everything going on in the computer, all of the
But, put psh on top of Perl.NET and we've got a really capable setup. Sign me up! Perhaps psh+mono could be the OSS/FS community's answer to MSH on
They're missing the point (Score:2, Insightful)
Instead, Microsoft wants to have a massive Borg-like internal heap of objects and functions, and give you a text interface to it.
I'd much rather have lots of little, self-sufficient programs that essentially *are* the OS, rather than a new view into the OS.
Yes, having function-level access and object manipulation sounds really cool and orderly compared to the barbaric pipe & grep. But when all goes to h3ll, you'll wish you had text.
Text is universal. Objects and function calls change like the wind.
Re:think for a moment (Score:3, Insightful)
People who propose systems like MSH want to iterate over files and all that good stuff using object oriented scripting features. I'm saying: that turns out not to be very useful in practice. The fact that psh happens to be able to emulate sh behavior is completely besides the point.
It is 'conception' that is basically the problem - you don't know what it is like to use a real scripting language from the command line so its strengths are not apparent.
Sure I do: I have used psh at times, and I have used Smalltalk and Lisp, which are much better at this kind of integration and scripting than even Perl or MSH.
But that kind of design of interactive shells, something that integrates full programming, has always lost out in the real world.
In fact, UNIX has a much better answer: rather than trying to force everything into the same address space, it provides facilities (environment variables, etc.) that let software written in multiple different "little languages" co-exist as if they were all part of a single, unified scripting environment.
If you want to use Perl in a script or pipe, just say "... | perl -e '...' |
The UNIX approach is great; you should give it a try sometimes. MSH and psh, on the other hand, are Microsoft-thinking: obvious, gimmicky, and not all that good in the end.
Re:The difference: (Score:3, Insightful)
Finally, they're starting to appreciate the unified namespace that unix has been offering since the seventies.
They're only doing it on a way to high level.
Everything should look like a file and be accessible through the same API. read(), write(), ioctl() and select() are all you fundamentally need to do with anything. Inband I/O, out of band I/O, and wait for event. What more could you want to do with any object whatsoever?
The unix model is so beautiful, too bad it isn't taken far enough, even in unix.
Microsoft has an especially long way to go if they're trying to unify all the different system objects on such a high level (the shell).