A Guided Tour of the Microsoft Command Shell 519
jpkunst writes "Ryan Paul at Ars Technica provides an in-depth, 13 page review of the new Microsoft Command Shell (Monad). (The beta release can be downloaded for free from Microsoft.) From the conclusion: 'Despite my initial skepticism, I am deeply impressed with MSH technology, and I am legitimately excited about the future of the Windows command line.'"
An open source clone? (Score:5, Interesting)
Another Wise Man Said... (Score:5, Interesting)
- Voltaire
Re:Oh, I am so excited! (Score:2, Interesting)
I'll stick with DOS batch scripts, thank you.
On The Pipe (Score:5, Interesting)
Reminds me of Python.. (Score:2, Interesting)
Seriously... I can see a Python-based shell that can do what MSH can (named 'pash', possibly?). I respect the SQL syntax used and it could be useful, although I dislike the idea of using |s for this (no real reason... it just looks/feels wrong).
Another downside (for me) is that it's too verbose. I'm used to short commands like 'cat' instead of something like 'get-contents'. And the
Just my two cents.
Re:Who wrote the introduction? (Score:5, Interesting)
In that case, that's a visual style that's changing only the aspects of the UI Windows XP changed. Windows border styles and new flashy button hover effects, etc. Think of it as a different theme/skin, not a way for them to change the UI design guidelines. "OK" will still always be followed by "Cancel", group boxes will still group UI elements with a relation, menus will still be part of the applications and not the dsektop, combo boxes will still be recommended only in "little space" situations, and so on.
Actually, Microsoft has released preliminary design guidelines for Vista [microsoft.com], and I was surprised to see how much can be directly applied, and is even recommended to be applied like that, to Windows XP.
Also, even in Windows Vista, just like in XP, can you still apply the Windows 2000 look & feel via a flip of a switch. That if anything should show that all they're really doing are mostly just applying new skins to sell their product, and not coming up with new guidelines that indeed would alienate their broad customer base. If I'm at some user that have applied some simple settings, I often lose myself in thinking I'm working on a Windows 2000 workstation when I'm in reality on XP.
The why (Score:3, Interesting)
For a long time, it has been proud of his UI technologies, and thought the UNIX shells are too complicated to most people. As for the genernal people, it's right indeed; but it's not true for those developers that want to perform some customized tasks through some kind of relatively easy method.
The real problem is, Linux has been attracted more and more developers, it's absolutely dangerours to the Windows future. it must do something to change this situation, as a part of a series of actions according its plan.
Unix shell argument parsing (Score:2, Interesting)
>format mechanisms, MSH commands (called Cmdlets) all inherit a single base class, which
>ensures that all commands expose the same methods, parse arguments the same way
That's not entirely true about Unix (Linux): first, it omits to mention that Unix shells traditionally expand pattern matches in the given arguments, and match the command to an executable, before passing the arguments to that executable; and, second, everyone has used getopt(1) or getopt(3) (in whatever language) for years now, haven't they? (It's a common Unix newbie misapprehension to think that each executable has to expand the shell filename pattern matches in the arguments itself). These are a good start at maintaining command format consistency. I regret only that the original (Research) Unix didn't define which of: '-d -i' or '-di' and which of '-darg' or '-d arg' was preferable, and POSIX.2 (1991) appears (to me, glancing at it now) simply to have rubber-stamped the original situation.
Re:Some Wise Man Said (Score:1, Interesting)
--Dave Cutler
What a weird MiSHMaSH (Score:5, Interesting)
Seriously though, the design of MSH is odd. Their hybrid of paradigms from functional programming and OOP is just weird and inconsistent. Having completely different syntaxes for invoking "Commands" and "Methods" is obviously a byproduct of trying to have both a traditional shell syntax and OOPy goodness, without thinking much about internal consistency.
Typical Microsoft: very use-case focused, at the expense of helping their users build a consistent mental model of how their system works. I bet it's pretty hard to do anything in MSH that its designers didn't specifically anticipate.
I'm surprised none of you have seen it. (Score:1, Interesting)
Microsoft is doing NOTHING that is new here. NOTHING that they haven't done before, that they couldn't do before and that anyone else couldn't do, better in some cases.
Why are they even mentionning this?
Look to the law...
What do they wish to lever this against? The Unix command shell. Is bash copyrighted? Is it patented? Watch for assaults on technicalities...
If the law is against you, argue the evidence.
If the evidence is against you, argue the law.
If the law and the evidence are against you, give the opposing counsel hell.
Microsoft bears close watching.
Re:On The Pipe (Score:3, Interesting)
Interactive Ruby Shell (Score:4, Interesting)
http://www.rubyist.net/~slagell/ruby/strings.html [rubyist.net]
Wow, interesting! (Score:2, Interesting)
Re:impressive (Score:5, Interesting)
Followed closely by: It's a security nightmare waiting to happen. If people think BASH viruses are a potential problem then imagine the full horrors of ActiveX with access to a system shell. At least Mozilla exploits don't lead to "rm -rf
Re:Who wrote the introduction? (Score:5, Interesting)
Are they keeping things like "OK" and "Cancel? Yes. Are you able to change the look back to Windows 2000 (well, sort of). Yes. They do things like this so people don't need to totally retrain.
Is the user interface anything like Windows XP, under the hood? No. God no.
The entire thing has been rewritten from the ground up. Everything is a
What this means is they CAN make drastic changes down the road by simply changing a few objects. Everything will inherit down. Ever notice that buttons can be totally dissimilar from one app to the next, and all MS has been able to do is (for example) but a blue highlight around them? That's because the UI has been so cripped.
The new UI is simple, beautiful and brilliant. Is it completely different than Windows XP? No. It's not intended to be. The goal, like
Re:Hypothetical for the Linux Crew (Score:5, Interesting)
Hypothetically: What if MS pulls it off and puts out the best OS that the Linux guys have ever seen. Let's say it's the Longhorn Server, WinFS, Monad, and everything MS has been touting works... Will the Linux guys at that point stop bashing MS? Will you consider using the MS OS?
You're attempting to formulate a "what if" scenario, but as often happens you've oversimplified things on such a scale that it is meaningless. Linux admins do consider using MS products now, and deploy them occasionally where appropriate. As for "what if MS put out a better OS" well, I guess that depends upon what you mean by a better OS. The case for Linux vs. MS is both technological and business. Suppose the next version of Windows is technologically on par with, or better than, Linux as a server. It will still suffer from not being free of cost, not being customizable by the end user, locking the user into a single supplier for a critical component of a system, and putting customers in the position of having to deal with a company renowned for putting it's customers out of business using unfair tactics. No smart businessman wants any of those things. Even so, in some cases it makes sense to put up with those problems, and that is what smart administrators do.
For example, If I run a smaller business and need specialty software only available commercially on Windows and I don't have the resources and contacts necessary to build a open solution on an open platform, then it makes a whole lot of business sense to buy a Windows machine, at least for that one component. If, on the other hand, I'm working for IBM or a company with similar resources, there is rarely any compelling reason to go with MS for anything, since the resources are available to get a better long-term ROI and TOC by using open source solutions. Why lock oneself into paying a competitor every year, with no competitive bidding, when for a slightly higher initial investment a free alternative, with free development, and some free support can be created, that also places IBM in the position of being a market leader in that particular niche and ties into the bread and butter services business.
A good analogy might be, you invent a new desert pastry and it needs a fruit filling. You can use oranges, which you can get from any number of vendors, or grow yourself or you can use MSFruit which is patented and you can only buy from one supplier. Even supposing MS gains the edge in harvesting and processing technologies, does it make sense to sign a contract to use them as your sole supplier and agree to never alter your recipe or does it make sense to invest in better harvesting and processing technologies and keep using oranges so that you can take competitive bids and experiment with new recipes?
Of course, as you said, this is all theoretical. MS is so far behind other solutions in so many areas that they have not even tried to address that it is unlikely MS will catch up any time soon. The fact that they keep introducing anti-features designed to benefit MS as a company and cost customers extra money somewhat counters other advances they make. They pay a lot of attention to bullet points and making things "good enough" while not really achieving that for a good portion of users. They have a few nice features that I'd say are better and more usable than anyone else, but at the same time they are really really behind in other areas and falling further behind all the time. Don't call me when they have pipes and scripting that work without writing any code and from the GUI. Don't call me when they allow programs to offer services to other programs. Don't call me when they fix the disaster they call managing programs. Don't call me when they no longer expose network services by default. Don't call me when they move to open APIs. Don't call me when they open and document their formats and support other open formats. Don't call me when they have workable non-admin accounts. Don't call me when they make the UI responsive during heavy multit
Script to convert Office to OpenDocuments? (Score:2, Interesting)
Re:impressive (Score:3, Interesting)
There's a big difference between should never and will never however. You may have to cope with malformed data, text streams from the WWW, archaic media, inputs from legacy screen scraping applications. Sometimes the ability to slice text up by column is useful. We don't use cut much on Linux either as it happens.
Sure, you *can* still pipe raw text from one app to another, but it's not correct behaviour for programs written for MSH You may have misunderstood my objection. I have no idea if Microsoft are offering something like cut. But that's missing the point, because your scenario should never occur under MSH.
There's a big difference between should never and will never however. You may have to cope with malformed data, text streams from the WWW, archaic media, inputs from legacy screen scraping applications. Sometimes the ability to slice text up by column is useful. We don't use cut much on Linux either as it happens.
Sure, you *can* still pipe raw text from one app to another, but it's not correct behavior for programs written for MSH
Which probably the difference between Bash and Monad in a (pardon the term) Nutshell. Because bash is designed as a glue language with a toolkit aimed enabling compatibility with other data sources. From your description of Monad however, it seems determined to restrict the user to a Microsoft environment. Certainly that would fit with MS strategy to date.
incidentally, I don't have a problem with the assertion that Monad is a more powerful scripting environment than bash - proper comparison is, IMHO, with perl. Bash is optimised for command line use first and foremost, whereas Monad seems to be written mainly for scripting. I know there's all the hype about it being a new command line shell, but I suspect a lot of that will turn out to be marketing hype. There's a command shell module for perl as well. I've never heard of anyone using it for day to day use though - Perl is optimised for scripting. From what I've seen, I think that'll turn out the case for Monad too.
Incidentally, I don't have a problem with Monad being more powerful than bash; Perl or Python would be a better basis for comparison. Bash is optimised for command line use first and foremost, whereas Monad seems to be written mainly for scripting. I know there's all the hype about it being a new command line shell, but I suspect a lot of that will turn out to be marketing hype. There's a command shell module for Perl as well. I've never heard of anyone using it for day to day use though - Perl is optimised for scripting. From what I've seen, I think that'll turn out the case for Monad too.
Pointless? (Score:0, Interesting)
I don't see a reason to work on a OSS implementation of Monad -- which is a great name incidently, Liebniz is a good read. It was pretty sad to see scores of "lol, monad... gonad.. lolz, whats a book?" posts when it was first announced.
Anyway, I digress.
Monad exists to catch up with unix shells. We've already got them. Monad doesn't really offer us anything we don't already have. Monad has its own ways of doing things that are different from ours, but the end results are pretty much the same. Python's shell has the whole OO thing going for it anyway, if thats an appealing idea.
If someone clones Monad to linux, then its because they are a very strange person. Since very strange people exist, it'll probably happen, but it'll never catch on with the rest of the linux community, except possibly in some of the crazy windows-a-like-linux distros.
--SD
Re:A shell is nice but... (Score:5, Interesting)
Very valid concern regarding the Windows platform. You can indeed do most of what you need to do in Windows through a command line if you are a guru, however without Monad Windows command-line capabilities are extremely weak. Regedit can be used at the command line, however it is quite cumbersome--especially if you must browse the registry. The whole concept of the registry puzzles me actually--here is this obsfucated, hidden, monolithic configuration file that holds all this important system information and if it were to be corrupted it could potentially make the machine unusable. In order to manage it, MS spent the time to greate this regedit program to decode the registry and present it as...a filesystem-like tree structure. Good Lord, what the hell for? When MS was addressing the problem of
If that sounds almost like a UN*X
Fortunately MS has seen the light and it appears that they are trying to quietly re-invent Windows in the image of UN*X. Of course, they won't admit their mistakes and copy UN*X/Linux design outright--they are re-architecting Windows using the same concepts but their own dialects (and in some cases they are making improvements to those concepts). This means that Microsoft can claim to be "innovating" instead of fixing bad design decisions. Some examples of the direction MS is going:
* Monad--an "object oriented shell" that brings a modern image to a very old idea. MS is acknoledging that the command line really IS a good adia and not obsolete, and that it was a mistake to neglect its command line shell. The object oriented approach and consistent interface is a modern solution to a problem originally solved in part with pipes in UN*X. Python provides an object-oriented shell on that platform now--but MS just polished the idea a bit and made the whole shell solution more unified.
* XML-based config files. You won't ever hear Microsoft admit it, but the system registry is a flawed concept and the implementation in Windows was so bad it was a significant source of relaibility and security problems. If you look hard enough in MSDN literature and in blogs, you will find that MS is quietly pushing developers to eliminate their dependency on the registry in favour of
* Microsoft has been slowly expanding developer options for creating GUI-less applications (services and console apps). Prior to VS.NET (right up to version 6) to do so required using C or employing awful, unsupported hacks (anyone who has tried writing a VB6 console app or service knows what I'm talking about--the required hooks into low-level Windows APIs make the result so ugly you are best advised to give up and use C anyways). Now MS has the CLR and
Re:Who wrote the introduction? (Score:2, Interesting)
AKA "Single point of failure". At least with 5000 config files, if just a few of them get hosed, you can rebuild them easily. Your registry has something happen to it, you might be doing a complete restore or reinstall.
And the long march continues to ubiquity (Score:1, Interesting)
And here I thought I was all alone, a single voice crying out "beware!" to millions of deaf ears...
Seriously, this is one of Microsoft's big targets at the moment - to be the man in the middle. The goal of Microsoft is not dominance by monopoly; rather, it's one of many stops on the way to being the middle-man for everyone; dominance by ubiquity. They want to be at the center of it all; the monopoly is just a means to an end for them. I've often wondered how much longer it would be before Microsoft started to push "their" ads and sites (which in turn generate side revenue) but then I realized that crap like MSN already does this. Slate is MSN with a premium attached; kinda like subscribing to cable TV so that you can get local channels that you could have gotten for low-cost or no-cost. Hasn't anyone noticed that Windows XP calls Internet Explorer "The Internet", instead of what it really is (and yes, I think it should be renamed "Large Steaming Pile of Dog Crap")? Again, we see MS trying to assert themselves "in the middle". Programming for Windows means "being in the middle" and "making decisions for everyone else". More of the same thinking.
>> Registry + ActiveX + functional shell (finally) + .NET = cataclysmic user-base catastrophe waiting to happen
>> Windows admins are screwed. Get out of IT now if you're still sane, get out even if you're long past sane. Life will become hell very soon.
As if it already isn't?
As if we don't already have daily fights for security against legions of web-browsing idiot users who think "The Internet" is the same as the Big E on their screen? As if the constant onslaught of "critical" patches weren't enough? Don't we 'Windows Admins' just love the ever-mutating strains of Virii that keep coming through?
Programmers don't have it too well either. What about the constantly changing API - the moving target that's known as Win32? It's great you just finished your in-house program this week to use technology "Y", but with new Microsoft "Z" tech, your program is almost obsolete overnight, and shortly thereafter, APIs for "Y" will be "legacy" status and abandoned. That means a rewrite for "Z"; and when you finish "Z", MS will point out how it doesn't work well either, so they come up with "A" and the whole fucking process starts over again.
I can see where Monad would address the issues that WinNT has had all along (i.e. how do I import 1,000 users from a text file and turn them into user accounts) but I can also see where it is just another vector for abuse. Monad continues to embody the same "we must be in the middle" thinking that Microsoft has had for a long, long time. The problem is that security is so poor that attacks are going for where Microsoft wants to be - in the middle, where you can control everything. Until there is a fundimental change in the group-think on the Redmond campus, and Microsoft as a corporation starts to really care about their customers, we will continue to have steaming loads of crap foisted upon unsuspecting IT staffers everywhere.
Deffinatly needs some work (Score:3, Interesting)
1) They still have the problem of cuting and pasting GUI environment info to the cmd shell window.
2) They are still limited to crappy display levels for the cmd shell window
3) If your building a verbose object oriented language you need a better refferencing system. Insane long wordy names are in theroy good and makes learning easier. But for repetative stuff it gets old typing them. Sure you can denote aliases... but why not always denote one by default? Just establish a best practices for creating a unique shorthand of the longer name.... and build it into the script to check with help to make sure its not walking on anything else. I garountee anyone that uses this thing for any length of time is going to create a shorthand for it... if there is one by default it will make it easier for people to talk it without first establishing what they all call their aliases for which function.
4) More works but is not listed under help. It has a flaw in that when you advance a single line it continually types the instructions just under the new line without deleting the old line... ie if you advance by line you then have alternating document info and instruction lines rather than the document txt incremeting above the instruction line ie...
(q)for quite (cr) for next line (space) for next page
Line of text from the file
(q)for quite (cr) for next line (space) for next page
Line of text from the file
(q)for quite (cr) for next line (space) for next page
Line of text from the file
Extremely annoying.
Some other thoughts.
Why are they trying to limit themselves to creaky old txt displaying methodologies ? Yes a command line consists of text information primarily but the reason it evolved in such a constricted interface was that there was no other option at first. Just because it is a command line does not mean it could not also be a gui. Give it the power of both. For instance lets say I open my computer. I get the standard drive icons etc and at the bottom I get a prompt. If I double click C or type cd c:\ at the prompt the same results happen on screen. Lets say I drag a file down to the command line.. now a token appears there for dealing with that file. I have a graphical rpresentation as well as text information and I can interact both with a mouse and with cmd line input.
Additionally they spent a crap load of time developing a pretty slick interface in the Studio
The marriage of the command line and the GUI is the next generation. It does not have to be EITHER OR. Both have strengths and both have weaknesses. Instead of being stuck with one or the other create a system that allows you freedom to use both sets of strengths to offset the others weaknesses.