Microsoft has released beta 3 of their Monad shell. “Windows ‘Monad’ Shell is a new interactive command-line and task-based scripting technology in Windows that enables administrators to more efficiently and securely automate and control system management tasks on both desktops and servers. ‘Monad’ Shell provides powerful task-based control (via built-in command line tools and utilities) and a powerful scripting language that enables comprehensive scripted control of the Windows operating system and applications.”
The download you requested is unavailable. If you continue to see this message when trying to access this download, go to the “Search for a Download” area on the Download Center home page.
works here.
nice to have a new shell that keeps up with unix ones (finally). now a decent terminal wouldn’t hurt
I didn’t want to give them my main email address, so I used one that I don’t ever check. Unfortunately, I was then presented with instructions to open the email they had just sent me to download the shell. Well, I used the browser’s back button to go change to a valid email address, but it took me to the Monad description page, so I clicked the continue button again, and it just downloaded the shell this time!
Long story short, you don’t need to use a valid email address to get Monad.
If you realy think Microsoft is going to spam you then you are seriously paranoid.
Will Monad be a part of Vista?
According to http://www.pcworld.com/news/article/0,aid,122145,00.asp Monad was pulled from Vista due to security concerns. Basically, they thought it would be too much of a target for hackers.
The PCWorld article is wrong in two aspects.
Microsoft will not include Monad in Windows Vista because it will not be ready in time for them to fully integrate and test it with that product, not because it poses a security threat.
Consider the current Windows Command Prompt. If a user has the proper privileges, he can issue destructive commands, or run a script with such commands. If he does not have the needed privileges, the commands will not execute. The same is true of Monad.
Demonstrating that a user can execute malicious commands from a shell does not mean one has discovered a security risk.
They did discover the wheel…
And shall make money out of it (at least from publicity)….
Did they say “‘Monad’ Shell provides powerful task-based control (via built-in command line tools and utilities)”?
I can’t believe it! Who had the idea?
Actually there is a big difference. In Monad you are able to pass objects around, vs. the text based interface that Unix shells typically provide.
Whether thats a good idea or not is an entirely different discussion….
Objects or text, the question I really want to know is if there will be a text based way to make changes to the registry. in *nix’s it’s easy to do text base remote adminstration. you can modify simple text files. (that change format based on OS)
Adding items to the registry from the commandline is easy. But how do you make minor modifcations?
My one hope with monad is that it will inspire some new ideas for *nix shells.
I really want to know is if there will be a text based way to make changes to the registry.
Yes, IIRC. There’s what they call ‘Registry provider’ (another provider is ‘File System’, etc),
You are able to go something like this:
cd HKLM
cd Software
and then dir or ls, make changes to keys, etc.
<u>the question I really want to know is if there will be a text based way to make changes to the registry.</u>
http://www.computerworld.com/softwaretopics/software/story/0,10801,…
This article explains exactly how. Moving around the registry on the command line looks pretty cool. Actually changing it looks irritating because of the complex commands.
Like many people I am a fan of powerful command line environments. Using Windows has meant having to step down to the tinker-toy version of the CLI interfaces that Microsoft grandfathered into Windows from DOS. Even with additional tools that were eventually ported from Unix and with extensive native command line utilities developed by third parties the CMD16 and CMD32 have long been the weaker environments in which to work. In a direct comparison with Unix/Linux any Microsoft CLI will likely be the less capable given current working enviroments. And why is that? Because the Unix/Linux CLI’s developed in parallel with their operating systems and have evolved to manage them effectively.
And until now Microsoft’s CLIs have not evolved much. But now the DOS box has finally been re-imagined to integrate with the object-based environment provided by the NT-based operating systems. And the power inherent in this marriage of function is considerable.
So what changed? Someone at Microsoft finally looked at what the command line environment offers users at a very basic functional level. They considered what it does and how it goes about accomplishing its functions. They noted the stegths of Unix/Linux CLI’s use of pipes and of the file system metaphor for addressing objects. They noted the weakness in all current CLI’s dependence on converting information to text as a lingua franca for passing data between processes. They noted that while there was an expectation for exceptions to occur in common usage there was no mechanism for elegantly handling them. They then wrote out the weaknesses and in doing made fundamental improvements to the CLI. It is extensible, it has aliases, it makes most objects accessible (including processes, files, registry entries and data sets) and it uses simple rules logically implemented.
The Microsoft Command Shell’s strength is in how common sense these improvements are. It is a wonderful example of how elegantly a CLI can address systems administration and programming needs. It’s what BASH would be if you didn’t have to use sed and perl all the time. And if you aren’t ready to depend on it entirely you will find that all of your old CMD32 tools and utilities are still available, if redundant or unnecessary. So if you haven’t taken the time to play with it yet, you should.
I disagree about converting everything to text. Remember, human’s use the CLI too. One of the strengths of Unix is that everything is in human readable plain text. It’s never locked up in some opaque binary format that can be corrupted at the drop of a hat (like the registry). The extra effort sometimes required to do text manipulation is really nothing, especially with powerful tools that use, e.g., regular expressions. The learning curve is a little steeper, but overall, it’s more flexible and user-friendly.
I’d like to give you a few examples of what will be possible with Monad (which is in fact already available through WSH):
– you can create an IWebBrowser object, load a page and access its contents using DOM – useful for testing if a web page is working as expected or downloading hot topics from a news site, all that without having to parse any HTML,
– you can open Office, WordPerfect, probably OpenOffice and other files (for which the vendor has supplied a COM control) and modify them using published APIs,
– you can instantiate an XML parser object, which will allow you to access and create XML files using DOM,
– you can access databases using ODBC and (in Monad) ADO.NET,
– and lots more using OLE Automation and .NET.
I’d argue that this feature set is closer to PERL than to the Unix shells. In my opinion it’s also done in a much more clean way – using COM and .NET.
As for the part about “human readable plain text” – the simplicity of this approach has both strengths and weaknesses. There are situations where the weaknesses are starting to be a real PITA, and that’s what Monad is trying to address in my opinion.
I’d argue that this feature set is closer to PERL than to the Unix shells. In my opinion it’s also done in a much more clean way – using COM and .NET.
A small remark: PERL can also do COM calls.
Text certainly has proven its worth when porting information around between processes and objects. Textual information being used in the CLI isn’t going away anytime soon. And using Monad doesn’t mean you lose the ability to use text streams between processes and objects like you have been able to do historically. What it does do is deprecate the use of text by providing new tools for working directly with the objects that the text represents.
It’s probably going to be a question of taste and experience in how people use the Monad technology. If you are used to parsing out text streams to meet your needs then you may see little or no benefit. If you depend on data objects that can’t be directly accessed by Monad then you may see little benefit compared to other shells. Personally I work with operating system objects extensively and I find parsing text streams to be a tedious and fallible exercise. So the idea of piping a set of objects to a process and then allowing that process to decide which of the object’s attributes it is going to use without having to intervene my parsing between the object and the process holds a certain attraction.
I agree with you one hundred percent on this. Microsoft thrives on complexity. This is a well known fact. It is as if they are scared that the users will learn how the system works if they make it any simpler. Once you get used to the text file configuration of Linux/Unix, you will dread going back to configuring windows OS and dealing with its registry and such.
I imagine all these objects have a tostring method…
The problem I see with Monad being object based is this: It’s hard to implement. Unix shells are a snap to write, because they’re simple (at least the base requirements are).
They might be able to make monad easy to reimplement by simply including most of it in .Net. However, you’d still be stuck doing it in .Net.
Unix shells are very modular in that programs don’t actually depend on each other satisfying much. The rule is be strict with what you put out and liberal with what you take in. Making what’s passed into objects means being strict with what you take in and strict with what you put out.
I haven’t tried this beta. But the last one, or one before it was missing input streams, it had a note that it’d be done later. It was also missing the backquote operator, and there was no note about that. Do you suppose the parameters in monad are objects as well?
Maybe all of what you say is true. But, the most difficult thing I find about using the command line in Windows is not that you couldn’t accomplish things with batch file scripting. The problem is that it’s always like typing with 10 thumbs. For example, Windows forgets its history between sessions.
Another example is that the arrow keys don’t take you backwards from where you are in the history. They take you back from wherever you might have been in the history when you last used it. OK. That’s kinda hard to explain. So, let me give you an example. Say you are like me and you use vi to edit a *.cpp file. Then, you compile with gcc. Finally, you execute with ./a.out. In *nix, you can hit the up arrow 3 times to edit, 3 more times to compile and 3 more times to run your file. You can do that all day in *nix. But, in Windows, you eventually come to the beginning (or end) of your history.
Also, a good tabbed console like Konsole would be good. If Monad ignores usability, it will still suck to have to use.
You know, I don’t really find Windows scripting so lackluster. In fact, I don’t use Bash for scripting. I use Python. What I need is a good command line interface that will allow me write Python scripts in vi.
backdoc
The problem is that it’s always like typing with 10 thumbs.
Exactly.
I prefer to leave my hands in autopilot when I’m at the keyboard. I press CTRL-A to zip to the start of the line, or ALT-D to delete a word, but if I’m using CMD it doesn’t work. So suddenly I have to stop and think about how to do simple stuff instead of thinking about what I’m trying to achieve.
x64 build is also available:
http://www.microsoft.com/downloads/info.aspx?na=22&p=7&SrcDisplayLa…