The command line interface to the Windows Server OS will be changed to the new Monad Shell (MSH), in a phased implementation to take place over the next three to five years. This confirmation comes from Microsoft senior vice president Bob Muglia in an interview published today by Microsoft. ‘Monad’ Scripting Shell Unlikely to Debut in Longhorn says Mary Jo Foley though: Microsoft is planning to make its alternative to Unix and Linux command-line scripting available as part of Exchange 12, due next year.
I’m sure the new, more functional command line was scheduled to be a part of Longhorn?
Another thing that’s slipped?
MS inventing new and exciting features! Great!
The only thing that confuses me is that I thought it was the command line that made Linux unusable…
I agree that it can be very confusing if you end up dumped at the command line (for example if your X server dies), especially if you don’t know what you’re doing.
The command line offers so much flexibility. For example, bulk renaming or converting files is made easy. It’s also possible to string commands together using a pipe ( | ).
so, I could list every line in a file in alphabetical order under linux by:
less file.txt | sort
And list the number of unique lines in a file by:
less file.txt | unique | wc -l
apologies, my commands may be a little rusty.
Those are examples of things that may be difficult to do under a GUI.
I’m sure the new, more functional command line was scheduled to be a part of Longhorn?
Yes…
If MS continue to dump features of longhorn, in the end, it will be winXP with a new skin O.o
I totally agree with you.
My comment was merely meant as a joke, as you read comments about how Linux isn’t ready for $whatever, because of the command line in about every discussion about Linux.
I probably should have made it clearer, that it was meant as a joke.
Ralph: message recieved Just trying to be helpful
Felipe: And even then, the current XP skins are not as nice as Plastik for KDE
I thought Longhorn was originally promised to work without a GUI?
Longhorn was also originally promised to come with a lot of things
bout time they implemented a powerful CLI!
Can’t wait
I once looked at a demo on Monad (on channel9.msdsn I think). It is pretty impressive. Instead of byte streams, the commandline programs transfer a stream of objects between them selves. Yes… it seems to be integrated with .NET. So it is possible to wrap simple commands over .NET APIs and work with them in the object oriented fashion. It is very different from the way it is supposed to be in UNIX. I hope similar ideas come in Mono.
Why dont they just give it a Bash command line and be done with it? They are trying to re-invent the wheel just as Apple used to do with their “Classic” OS. Waste of resources if you ask me, but then again they can afford to.
Well you already have cygwin which lets you have your bash command prompt…
I’m a MSH beta tester and I can tell you all, don’t hold your breath. It’s an entirely new (and IMHO utterly difficult to use and script) shell with a rather screwed up syntax. Bash or CSH anytime!
I’d rather see them implement something like 4NT (from JP Software) than bash. Or maybe an option for both! 🙂
As long as they don’t give non Administrative users the option to type something like rm -rf / . I think it will at least enhance the ability for sys admins to remotely administer their systems without going through the accursed Telnet.
We all know that a GUI is nothing more than a CLI with window dressing. Maybe this is actually some parts of the current command set opening up to the public and advertised as a “new” and “innovative” thing.
echo “Microsoft is planning to make its alternative to Unix and Linux command-line scripting available as part of Exchange 12, due next year.” > /dev/null
what a pity that…
… becouse a good commandline was exactly what I was missing in windows
In unix you at least get to choose what shell you like best.
From what I understand the article is saying, they are not dropping Monad from the first release of Longhorn, but rahter they are integrating it into current MS products over a period of 3-5 years…I could be wrong though but that is what I got out of the article summary.
It sounds the same to me, they are adding it first to Exchange 12, then longhorn and so on. It also sounds like they will keep adding to it in these 3-5 years making it more powerful as time goes on, since it ties into .NET API’S maybe they will tie it into other systems also, maybe it can use WinFS when that is done etc.
All sounds very good to me.
i was an official beta-tester, but didn’t test much… i found it difficult to use, bash is easier. actually, monad is very advanced – you don’t pipe text, but objects. it’s really cool for scripting, like a good scriptable shell, but simple commands like “dir” are no longer working… the scriptlets are nice, but the whole monad thing is created to support the GUI, not to replace it. like the way you can do somewhing like ls | sort | excel. the actual command is very different, but you get the idea: pipe it to excel. and because you are piping objects, all the properties stay available. still i didn’t like the feel of it…
What does Windows CE do now? Does CE require a GUI?
5 years for a bash clone ?!
It is ironic that M$ and windows zealots love to say that linux/unix is obsolete because they use “arcane command prompt”…
It will be more dificult to be MC$E and there will be less reasons to not adopt linux if it is free (as freedom), it is flexible and it has already powerfull shells and it is fast and stable.
Haha! I thought the command line was anathema and should have no place in a mordern GUI.
It is, but for the end users, however it’s a blessing for admins.
No.. what people have been saying is the command line should NOT the ONLY option. Windows will not require anyone to use it, it’s just there for power users.
Well, it’s not a bash clone. Judging from what i’m reading,
it sounds like a python interpreter with a prompt.
If you want to have similar features on UNIX *today*, just change your shell to /usr/bin/python =oP
If you want more info and a video preview, go here:
http://channel9.msdn.com/wiki/default.aspx/Channel9.MSHWiki
More about Monad:
http://www.microsoft.com/technet/community/chats/trans/windowsnet/w…
I have been using Monad for sometime. I don’t recommend installing yet because it uses and old version of the .net framework version 2 and won’t work with the new one. Here is example of how easy it is to consume a web service in monad:
MSH> get-assembly QuotesService.dll
GAC Version Location
— ——- ——–
False v1.1.4322 C:Quotes.dll
MSH> $proxy = new-object Quotes
MSH> $proxy.GetQuote()
Not everything that can be counted counts, and not
everything that counts can be
counted. — Albert Einstein (1879-1955)
MSH>
And if you want to get the methods exposed you simple type
$proxy | get-member -m
Class Name MemberData
—– —- ———-
Method Abort Void Abort()
Method add_Disposed Void add_Disposed(Sy
Method add_GetQuoteCompleted Void add_GetQuoteCom
.
.
.
Its a very powerful language.
command.com was renowned for the incompleteness of its batch language, where you couldn’t do much with the for command; bash and the other Unix shells had a lot more programmability.
Microsoft is likewise famed for the incompleteness of its software – I’m wondering what they’ll leave off Monad in order to ship it on time.
You right they are going to leave off somethings from V1. For instance there is no eventing model built in right now. They hope to have it in V2. Having said that it is still powerful and usefull.
It is unclear if it will be shipped with longhorn. All that is known is that it will ship with Exchange. My guess is they are unsure of security implications and don’t want to chance intrudecing new attack vectors. Hence they testing the waters with the relatively small group of Exchange admins.
It sounded like python to me at first, then I realized that it can communicate with graphical programs, which python cannot do.
then I realized that this communication is possible because microsoft created these programs so they can communicate with monad.
Meaning: most programs for windows won’t be able to communicate with monad, simply because their creators were educated by the Windows GUI model to build programs that send the output as a nice drawing to the user, and not as data to some shell.
Too many prograns will have to be rewritten to make monad’s potential even close the the shells potential in *nix.
And as a last thought: Microsoft made a GUI based OS, why won’t they create a GUI-based scripting language?
You drag rectangle shaped objects, connect them with lines (pipes), use ,for example, purple diamond shapes (variables) with arrows (assignment marks) to store data etc.
Or should it be invented in Xerox Parc and used in Apple first for Microsoft to get it?
What I’ve love to see is the ditching of drive letters; get rid of all that crap, and use something that is remotely usable in the real world; treating all devices as one big, giant storage pool instead of segregating it.
From the way you describe it; it sounds like they’re going to release it as part of Longhorn, and make their products ‘MSH enabled’, so that you can control ALL their products, either via the GUI or CLI; this will be a massive coup, especially for those who have been whining about how crap the CLI tools are.
Well, this looks as MS is using a 100% different way of approaching the problem: in Linux, the GUI is the frontend for the console while in Windows the console is going to be a way to control the GUI.
It will be interesting to see which way will turn out better. I like the console-oriented one more because it you want to, you can use it without any GUI (great for servers and clusters and Linux farms), however in the MS approach the GUI/the whole app will be hanging somewhere eating valuable resources. I’ve used COM to control MS Word and my application had to wait while Word loaded its 7-megabyte library. It even displayed itself in the taskbar!
Has that got anything to do with Haskell monads? Will it use Haskell’s powerful type checker?
And as a last thought: Microsoft made a GUI based OS, why won’t they create a GUI-based scripting language?
You drag rectangle shaped objects, connect them with lines (pipes), use ,for example, purple diamond shapes (variables) with arrows (assignment marks) to store data etc.
While that would work and look quite nice for small programs, it quickly gets unwieldy for anything you can’t fit in a few lines of text.
Also, you’d still be working on the same level of abstraction, so you wouldn’t really make things any easier.
I sometimes have to submit a Finite Element calculation job on a remote machine. Under any *NIX shell I know, it is very easy and powerful to navigate around, copy things look up some help pages etc.
I once came across a Windows box and it was HELL. And I am not referring to differences in the commands (ls -> dir) I got used to that quickly. I had my main gripes with a NOT WORKING TAB KEY!!!! Imagine how often I hit the TAB key only to get frustrated by the fact that nothing happened. Additionally there was no way to get the middle mouse button work correctly.
So hearing Microsoft improving the command line is REALLY GOOD NEWS! Hope it happens before I retire (I am 31).
Tab completion for directories and filenames is a cmd option that is not enabled by default on all systems (should be on XP and up).
“cmd /?” (without quotes) will give more info on this, however, on at least 2000 and XP (and their respective Server versions), it can be enabled by typing “cmd /F:ON”.
If Tab doesn’t work, try Ctrl-D for directories and Ctrl-F for filenames, both of the keys for these options can be changed (eg., to Tab) by editing the registry keys detailed in the documentation from “cmd /?”, or by using the TweakUI powertoy. On XP/Server 2003 systems, simply enabling the feature (cmd /F:ON) should enable completion using Tab. Set this switch in the shortcut to cmd if you want it enabled anytime you launch cmd.
MSH is made primarily for non-GUI local and remote management. It’s basically an OO version of Unix utilities w/ a standardized syntax. The WMI commandline interface (wmic) currently available in Windows is probably closest to MSH but still isn’t directly comparable. If an app isn’t built with MSH in mind, you can directly access the functionality provided via COM (if that interface is available) or some other method that may involve GUI manipulation, but there will be a number of apps that will expose their functionality via cmdlets (or existing apps whose functionality can be exposed as cmdlets by the end-user or dev), Exchange is just the first. Much of the OS admin and policy functionality will be exposed to MSH.
Microsoft keeps chipping away at Longhorn’s original goals. I have a bad feeling, that all we’ll be paying for in Longhorn is a cosmetic make-over
I think you’ll be surprised, and I think Foley’s article is largely wrong as far as there being no MSH in “Longhorn”.
Of the originally promised functionality, only one pillar has been removed (WinFS) and it will be in beta around the time “Longhorn” ships. Indigo was always multi-platform. Avalon on XP will be basically like Win32s on Win 3.1 vs. NT 4.0 or Win95. It’ll provide a compatibility layer so Avalon apps can be made to run on “Longhorn” and down-level platforms, but the down-level platforms will take a hit in performance because they don’t have “Longhorn” new driver model and kernel changes. They also won’t have the new interface, so you’ll still be limited to XP’s usage model.
MSH sounds like something that *nix has had for many, many, many years, only with a proprietary and re-engineered syntax.
Pipes. DCOP. Sockets. CORBA. Rexx. MSH puts a new slant on solving problems that have been solved for many years now.
In other words, MSH is just a rehash of someone else’s long-standing idea, only more weighty, by the looks of it. Innovation, my buttocks.
@ Zlogic
You can actually run Windows in headless mode (no GUI).
@Shaman
First, are you saying that Microsoft should not add this functionality that is already available? Are they wrong for doing this?
Second, it’s not exactly the same, there are some differences, and they approach some things differently.
You can run Windows 2003 Server in headless mode.
Well, why would you want to run Pro or Home in headless mode?
Someone mentioned python, try ipython (http://ipython.scipy.org/) for a nice interactive shell.
Headless mode in Windows Server still fires up the complete GUI part of Windows.