Next-gen Windows Command Line Shell Now in Beta 668
Suddenly_Dead writes "Microsoft's new command line shell, MSH or Monad, has entered the beta phase. Channel9 Wiki has information on how to download this (complete with Guest ID), and other related info."
No Thanks (Score:2, Insightful)
I'll stick with bash or ksh, thanks very much. But thanks for trying.
Re: No Thanks (Score:3, Insightful)
Ok, but does bash or ksh run on windows? This is for their own OS, not unix.
So to answer your question... no... it doesn't remind me of that quote, because it has no relevance to it.
Re: No Thanks (Score:5, Informative)
Of course it does, silly [cygwin.com].
Re: No Thanks (Score:2, Insightful)
Re: No Thanks (Score:5, Insightful)
Talk about proving the quote right.
That's all bash is. That's all it does in linux too. You use other programs to do the work, bash is simply an interface to the file system. And a damn elegant one at that.
Re: No Thanks (Score:3, Insightful)
Re: No Thanks (Score:3, Interesting)
Really, it's new territory for them, they have a poor track record, and this has "lots of hooks into the Windows kernel and various low level functions". Sounds dangerous.
Re: No Thanks (Score:3, Interesting)
Nobody said it was easier than the UNIX way, though for day-to-day operations it shouldn't be any more difficult. Where you'd find yourself writing a bash, perl, or python script in *nix, you'd write a msh script in Monad. Where you'd find yourself needing to write an actual application to do some work (think ps or grep), you'd write a cmdlet as a .NET assembly (or even write another msh script). The difference is in how much more powerful MSH script
Re: No Thanks (Score:3, Interesting)
Talk about proving the quote right.
That's all bash is. That's all it does in linux too
The problem is, UNIX is built around an "everything's a file" abstraction, so having a file-based CLI works wonderfully for it. Windows doesn't really support that abstraction nearly as well, so for many essential system tasks you need non-file-based interfaces. MS have been starting to provide these with tools like
Re: No Thanks (Score:3, Funny)
SFU is a joke. What kind of circus you running there?
Cheers
Stor
Re: No Thanks (Score:2)
Sure they do, like almost all Unix software, either via the full blown Cygwin or via the more lightweight MSYS.
Re: No Thanks (Score:2)
The OP is trying to say that they are reinventing Unix with LH, evidenced by the new virtual folders, file permissions, new scriptable shell and so on.
Re: No Thanks (Score:2)
Re: No Thanks (Score:2)
Yes they do actually, ever heard of the cygwin portability library/distribution.
Because of that I have all manner of unix/linux/bsd utilities that have been recompiled for windows. I can diff, patch, make, ./configure, gcc, vi(m), emacs, bash, ksh, lynx, wget, scp, ssh and even use x.org to my hearts content. It's a good compromise when you have to stay on windows for one reason or another.
Re: No Thanks (Score:2)
As a matter of fact
Re: No Thanks (Score:2)
Re: No Thanks (Score:2, Funny)
Re: No Thanks (Score:4, Interesting)
Re: No Thanks (Score:3, Informative)
'cause 95% of us think that ksh is a horrible, horrible shell, and that bash "rulez".
Re: No Thanks (Score:3, Informative)
Re: No Thanks (Score:2)
Re: No Thanks (Score:5, Insightful)
Re: No Thanks (Score:2)
I'd welcome something brilliant in MSH but somehow (given their lack of creativity) I'm not holding my breath. Love and Peace and all that - I'm not interested in flame wars.
Re: No Thanks (Score:3, Insightful)
Re: No Thanks (Score:5, Funny)
Because we're Unix zealots dumb ass. Get with the program.
30 years in computer years? About 1000 years (Score:5, Funny)
They basically got it right.
They must have, otherwise it *would* have been redesigned or have fallen by the wayside decades ago. Decades, in IT. *Decades*. Think about it.
Sure, something may well come along which is "a better way" but I doubt it'll be MS who come up with it, they don't have a philosophy so I don't see how they could.
Re: No Thanks (Score:5, Insightful)
Yep, that'd do it for me :)
Re:Drop the marketing jargon for a minute! (Score:5, Informative)
Actually, I think I have heard/read that since Windows 2000 (and maybe earlier for the NTs), every administration task in Windows was required to be manageable via command line, as well. Something like that, at least - there certainly are a lot of command line apps in
I don't know what exactly makes cmd.exe anemic - it's perfectly fine, in my opinion. It's not as powerful as bash or the other Unix shells, and the scripting is terrible, but it's just fine for basic interactive file management and the execution of command line apps. It does name completion (command.com didn't), which is basically THE killer feature for me.
There is no clear way to interface with the system, such as with kill -SIG PID (granted, this is because Windows is void of a kill binary); the intent behind this is likely the design philosophy of Windows. Ships with every Windows post 2000, I think.
As for other interfaces with the systems, like I said, there is a lot more than what you expect. The NET command certainly is well-known and used for about a thousand things, notable starting and stopping services. It certainly beats the rc.d scripts from my point of view, although I guess that's just because I'm used to it.
That said, one of the first things I do in a fresh Windows install is get Cygwin along with some Unix essentials - grep, wget, etc. And ls for the pretty colors.
Re:Drop the marketing jargon for a minute! (Score:3, Interesting)
I still script quite a bit in bash, since it's simply more portable, but scripting in Windows really isn't all that painful anymore.
Re: No Thanks (Score:2)
Re: No Thanks (not UNIX, VMS!) (Score:5, Informative)
Actually, in this case it should read...
Those who do not understadn VMS are condemned to reinvent it, poorly
Monad is heavily influenced by VMS, not the UNIX shell.
From an interview [microsoft.com] w/ the Monad developers.
MSFT Jeffrey Snover (Expert):
Q: I've heard Monad has VMS roots... will we have a utility or functionality similar to VERB to create our own verb commands and parameters?
A: We are very influenced by the VMS (and AS400) environments. That said, we don't have the same set of utilities. Do define you own command, you write a
Re: No Thanks (Score:5, Insightful)
The Monad shell may be nice. Heck, it may turn out to be superior to any *nix *sh shell. When it comes right down to it, though, the Windows developers are not going to begin rewriting all of their software just to make it command line compliant.
Monad is doomed, not by Monad, but by Windows.
Here's a Screenshot (Score:5, Funny)
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\>
Re:Here's a Screenshot (Score:3, Funny)
What I'm wondering... (Score:2)
Does this new shell have a 'ln -s' command? I guess not, since no reports (I've heard) of the filesystem have mentioned symlinks.
Did I mention how much I hate not having symlinks in Windows? A new usuable shell is all dandy, but I'd like symlinks as well.
Re:What I'm wondering... (Score:3, Informative)
In XP it was renamed as reparse points.
Re:Here's a Screenshot (Score:3, Informative)
This is what Microsoft has been "fighting" for! (Score:5, Funny)
Re:This is what Microsoft has been "fighting" for! (Score:2)
Here's a quote that I thought fit this article. "The cosmic operating system uses a command line interface."
This is fantastic news. (Score:4, Funny)
Monad? (Score:5, Funny)
Re:Monad? (Score:3, Insightful)
One shell to rule them all...
Re:Monad? (Score:2)
As a side note, MSH rocks! The idea that everything is an object that can be piped elsewhere is simple yet adds a world of power.
Re:Monad? (Score:3, Funny)
Most names people make up for products are stupid. This one might not even make it into release.
Re:Monad? (Score:3, Funny)
Sounds like a command shell that had one testicle removed.
No, it's plural. You know, like:
"Yo, you ain't no playa. I got mo nad than you, yo."
monad (Score:5, Interesting)
All the others use strings for piping.
Most *nix users i've seen writing online that tried it for a good while to really get used to it thoguht it was really good.
Re:If it's good.... (Score:5, Interesting)
It's rather sad to see people dismissing this so quickly. I can guarantee if this was an Objective-C based shell from Apple people would be slobbering all over it by now, and saying how innovative Apple were, probably with some jabs at Linux too. I remember seeing an initial presentation about MSH a while back and the thinking behind it impressed me then, I'll be keen to try this when it's fully released.
Re:If it's good.... (Score:4, Interesting)
Their bad (as in both -- nasty and foolish) ways of doing things are catching up with them all the time.
Re:If it's good.... (Score:4, Insightful)
Whilst the UNIX style unified directory hierarchy is aesthetically pleasing to computer scientists, I've never been convinced that it's really more usable. On Windows, people can learn a few simple letter to concept mappings "A" is the floppy disk, "C" is the stuff inside the Computer, "D" is the cD-rom drive, "E" is their usbEE kEE. Obviously not all systems will be like that, but it's common enough. On UNIX systems the location of floppy disks, installed programs, mounted USB keys and so on tend to move around unpredictably.
Incidentally, talking of legacy concepts, what do you think "mounting" is? It dates from the time when you had to mount tapes onto their reels!
licensing concerns (like XP workstation allowing only one user at a time);
I don't see how this would affect a command shell designed for personal use. I also don't understand how it only allows one user at a time - in the copies of XP I've seen multiple users can log in at once, then you can rapidly switch between them. If you are thinking of X and terminal servers, well, you can have a command line without that. Look at MacOS.
wide-spread security concerns resulting in the feature being turned off by default on most installations;
There's no evidence I can see that suggests this would be off by default. Actually MSH could be a lot more secure than the UNIX shell as it can be fully controlled by .NET Code Access Security, which is more fine grained than traditional UNIX permissions.
wide-spread fears of accidental and intentional incompatability;
By adding a new end-user feature? That never stopped them adding themes, Media Player, MSN Messenger, etc. Compatibility concerns for something totally new are far less serious.
being only available as part of an expensive (and extensive!) upgrade;
In contrast to what? Microsoft backport far more stuff than Linux vendors do, and Apple basically doesn't backport anything at all. That's $120 per upgrade, thanks very much.
Seriously. The guys working on MSH have blogs, I read a few, and they seemed very sharp to me. The MSH API seems quite lightweight and I suspect you'll be able to create new commandlets very easily - far easier than you can create new command line tools on Linux. Some of the examples they showed would require thousands of lines of code to write on Linux once you take into account the build system, the fact that they're usually written in C, the text parsing with extra checks for buffer overflows etc. Yet using the MSH API they fitted onto a single screen of text.
I'm not too worried, I don't use Linux over Windows just because of bash (surprise), I use it because it's Free (and it has some other neat features I like). Actually, most UNIX shells suck ass. Their builtin programming languages are hideously primitive, unintuitive, and are easy to screw up. Getting basic information out of common tools requires a guru-level knowledge of sed, awk and Perl style regular expressions which are themselves primitive, backwards and unintuitive.
You'd have to work pretty hard to produce a command line worse than the UNIX one (and no, cmd.exe does not count as "working hard", I suspect it's had about a weeks worth of work in the last decade).
Re:If it's good.... (Score:3, Interesting)
I guess the site's running it .... (Score:5, Funny)
... doesn't have a web interface...
First impressions (Score:5, Insightful)
My first impression - well, it will be fine for scripting, but as it stands it's appaling as an interactive shell - possibly slightly worse than cmd.exe as an interactive shell, and falling far short of bash/tcsh et al. The defaults for the commands seem way too verbose. If you're just passing objects around in a script that's fine - but for interactive use, it's just awful.
Re:First impressions (Score:3, Insightful)
It's that simple.
Short, cryptic names hinder usablity by greatly increasing the learning curve. "get-process" is far more intuitive than "ps", as "where" or "filter" is far more intuitive than "grep". If you find yourself typing "get-process" a million times, learn to type faster or alias it to something shorter.
Re:First impressions (Score:5, Insightful)
No, it is not. Neither is intuitive - a complete newcomer would have no chance of guessing either command. Both must be learned. Given that, I'll take the 2-character command over the 11-character command any day.
Re:First impressions (Score:4, Insightful)
Both must be learned and remembered. Longer names allow for an easier to remember naming convention that can then help you remember or find the command you wanted. Two letter commands are certainly easier to type, but as others have mentioned the command completion in the interactive shell should take care of that.
Re:First impressions (Score:3, Interesting)
In Monad, if I know how to get processes using get-process, I now know the "get" verb. Since the convention is standardized, if I want the content of a file, get-content is a good bet for the right command.
If I really don't know, I can do
get-command -verb get
to get a list of all of the commands that are getters.
Compare this with ls and cat which are just brute memorization. And good luck with apropos.
As
Re:First impressions (Score:4, Informative)
Re:First impressions (Score:5, Insightful)
As for the suggestion to alias commands so you don't have to type as much - wow, that's even more braindead. Part of the appeal of Unix is that the commands are pretty much the same everywhere - I can use grep to grep for things, for example, and expect it to work more or less the same on every platform. What you're advocating is the creation of an entirely individual set of commands, so administrators will either have to keep both sets of commands in mind (even more of a hassle), or be unable to (easily) understand each other because one abbreviated "get-process" as "gp", one used "ps" instead, and so on.
Re:First impressions (Score:3, Insightful)
It's that simple.
This is not a good argument. Default names become the standard. There are many reasons for this, but the top ones:
1. You go to someone else's machine, they have a different set of aliases
2. Re-install, have to realias it.
Good defaults are important.
Re:First impressions (Score:3, Informative)
Maybe it's because I come from a more Microsoft- than
whoosh! (Score:5, Insightful)
The Unix shell is the implementation of the Unix philosophy of small parts working together. It's the antithsesis of Windows' philosophy of providing everything possible through DLLs distributed with the OS.
For a shell to be useful, you need lots of little tools. Otherwise you're just trying to provide an isomorphism to the GUI, with command line switches and arguments taking the place of check boxes.
On the other hand, I suppose it's better than nothing.
Re:whoosh! (Score:2)
Re:whoosh! (Score:5, Interesting)
This tools are "commandlets." Being able to pipe
I can see MSH being a HUGE improvment over Bash. For example:
MSH> get-process
(IMAGINE A PROCESS LIST HERE, OR SEE THE LINK... damn
Want to filter that by virtual memory consuption?
MSH> get-process | where { $_.virtualmemorysize -gt 150000000}
(IMAGINE A PROCESS LIST HERE, OR SEE THE LINK... damn
In Unix, you have to parse string output and all sorts of bullshit in order to access a data field of some conceptual object, but with MSH I will be able to simply access it directly in a type-safe way. That is a huge improvement.
See more here: http://weblog.infoworld.com/udell/2004/11/02.html
Re:whoosh! (Score:5, Insightful)
List processses, order by memory consumption, saving 52 keypresses.
If you absolutely -must- sort out those that have less than n mem usage, try
$ ps vOr | awk '{if ($8 > 15000) print $_ }'
Still 15 less characters than your example...
Re:See... (Score:3, Insightful)
Alternatively, when you keep having to add new data on the *end*, instead of next to the columns that it's logically related to.
Re:See... (Score:3, Funny)
Of course nothing ever breaks with a Windows update.
Re:whoosh! (Score:5, Interesting)
Are you kidding? Parsing text is one of the hardest things for a modern processor to do. Having fields available in a consistent internal representation allows you to do stuff based on them without having to parse anything, and you don't have to parse things. How many regexen do you write in a typical shell script? I'm not saying there are no disadvantages to Microsoft's way, but speed isn't one of them.
Also, you don't have to launch so many processes with MSH way. *nix shells can be prohibitively slow if you use an iteration strategy that results in lots of processes being launched, but sometimes it's hard to set things up as a pipe because you often have to do more complex parsing.
These things aren't so much of a disadvantage for larger programs that often end up in another language, but small one-time scripts will probably be easier.
I'm not going to use Windows, but if someone can come up with something better than that stupid Python shell replacement on UNIX I'll give it a shot.
Actually it seems to me that new tools for the current shells could serialize objects and pass them through the pipes we have.
Re:whoosh! (Score:3, Insightful)
So, in this case, the "get-process" commandlet's author determines what data is available in its output (same as the "ps" author determined the availble information under Unix).
Basically, it's just as flexible as text output and parsing, without the overhead of writing and debugging regexps/awk scripts to get the data you want, as it's availab
Re:whoosh! (Score:3, Informative)
on the MS$ command line?
You can if you install the appropriate tools to do so, yes. Same as with any other OS with a command line system. I have ImageMagick on my system, so yes I can.
Can you do this ssh user@domain.com.
Yes, if you have ssh installed.
Can you run a firewall script from the cmd?
Depends what you mean by "firewall script". I don't really understand what you mean, but you might mean something like "netsh firewall se
Re:whoosh! (Score:4, Interesting)
It's just me, or you just said the same thing twice?
Unix has a lot of command-line tools, but it also has tons of libraries with no commandline attached to them.
There's nothing wrong with the Microsoft's DLL aproach either, they just have to provide a command line for the DLLs they want, programs which will happen to parse the command-line switches and pipes and use the DLLs to execute the real job. It's in fact a "perfect" policy/mechanism balance. Many unix command-line tools don't provide a library to be used by programs, very often I wish they would.
One Perl (Score:4, Interesting)
Re:One Perl (Score:3, Insightful)
Because in single user mode, or on a minimal install, that's all that guaranteed to be there.
Re:One Perl (Score:3, Interesting)
In fact, I wonder why we don't see more "Windows Distros". Bundles of Windows with preconfigured app/content packages. We see some insignificant bundles by computer retailers, like Dell, which include other apps
One benefit to Monad. (Score:4, Funny)
Anything would better! (Score:4, Insightful)
Or you could just download the release-quality one (Score:5, Funny)
Wasn't it already in the beta? (Score:2)
And with as verbose as it is, you might as well use a compiled program, or go with Perl or Python.
I find it ironic (Score:2, Funny)
Probably a very common business tactic, bash the competition and at the same time assimilate its best features, but still, poor style.
backslashes (Score:3, Insightful)
cd '/Program Files/Mozilla Firefox'
Re:backslashes (Score:3, Informative)
The NT kernel fixed the backslash brokenness years ago.
Re:backslashes (Score:4, Insightful)
Here's a clue, try learning something new once in a while...
Re:backslashes (Score:3, Interesting)
I'm not sure if going back to forward slash usage now would be a good idea, but variety isn't *always* a good thing. Some things are standard for a reason.
Re:backslashes (Score:4, Informative)
Monad?!?! (Score:4, Funny)
"Let's combine 'Microsoft' and 'Gonad'. It'll make Unix jealous."
shell bias (Score:3, Insightful)
honestly, the shell is just another language, the utility and efficiency of which depends on the environment, the use, the user, and a million other things.
so stop bashing Monad as a unix wannabe. unix didn't invent the commandline anyway. this is like a blind man making fun of a deaf man.
They tried this before (Score:5, Funny)
" I've been attending the USENIX NT and LISA NT (Large Installation Systems Administration for NT) conference in downtown Seattle this week.
One of those magical Microsoft moments(tm) happened yesterday and I thought that I'd share. Non-geeks may not find this funny at all, but those in geekdom (particularly UNIX geekdom) will appreciate it.
Greg Sullivan, a Microsoft product manager (henceforth MPM), was holding forth on a forthcoming product that will provide Unix style scripting and shell services on NT for compatibility and to leverage UNIX expertise that moves to the NT platform. The product suite includes the MKS (Mortise Kern Systems) windowing Korn shell, a windowing PERL, and lots of goodies like awk, sed and grep. It actually fills a nice niche for which other products (like the MKS suite) have either been too highly priced or not well enough integrated.
An older man, probably mid-50s, stands up in the back of the room and asserts that Microsoft could have done better with their choice of Korn shell. He asks if they had considered others that are more compatible with existing UNIX versions of KSH.
The MPM said that the MKS shell was pretty compatible and should be able to run all UNIX scripts.
The questioner again asserted that the MKS shell was not very compatible and didn't do a lot of things right that are defined in the KSH language spec.
The MPM asserted again that the shell was pretty compatible and should work quite well.
This assertion and counter assertion went back and forth for a bit, when another fellow member of the audience announced to the MPM that the questioner was, in fact David Korn of AT&T (now Lucent) Bell Labs. (David Korn is the author of the Korn shell)
Uproarious laughter burst forth from the audience, and it was one of the only times that I have seen a (by then pink cheeked) MPM lost for words or momentarily lacking the usual unflappable confidence. So, what's a body to do when Microsoft reality collides with everyone elses?"
source = http://www.flutterby.com/archives/1998_Sep/quicki
Ok, ok... fun's over--seriously now... (Score:4, Insightful)
Does this mean? (Score:3, Funny)
what can UNIX learn from this? (Score:5, Insightful)
No, this highlights a weakness in UNIX shells: we have to parse things. It's slow and it's a huge pain. It seriously limits what we can do. grep, sed etc can be used to manipulate streams but nobody ever implements the complete grammar of the input they can get. They implement some subset that's good enough for the job at hand and tweak it when it screws up. It's worked well for decades, but that doesn't mean we can't do better.
Having a data structure passed along a pipe like MSH does is a huge advantage and very efficient, but I think most UNIX people can agree that it's not worth it to bring everything into the same process. What's an alternative? Serialize the data structure (in some human readable form to stay true to UNIX tradition) and pass that down the pipe, from one process to another. That would work with the pipes we have now and the shells we have now, we just need new tools and a serialization protocol.
Re:what can UNIX learn from this? (Score:3, Interesting)
So when you ask "why does it do it that way?", the answer often starts with a description of how computers used to be used 30 years ago.
massive case of second system effect (Score:4, Interesting)
If you want to see some good (or at least interesting) directions people have taken shells into, there are Plan 9 rc (same idea as sh, but cleaned up), fish (better interactive features), and Tcl/Tk (shell-like programming for a full scripting language, including the ability to embed Java and C#/CLR objects). And if you want a full scripting language, Perl, Python, and Ruby fit the bill.
A note to FOSS programmers: if you are really itching to clone Monad, please do yourself and everybody else a favor, implement your clone in Perl or Python: a Monad-like shell becomes almost trivial in those languages because they have all the reflection capabilities you need, and because they already have all the hookups to Java, C#, and COM that you might want.
Quick Tour of Monad (Score:5, Interesting)
Very cool shell; if you don't know anything about it, don't assume it's just a bash or ksh clone.. it's actually something fairly unique.
Re:That's all well and good (Score:3, Insightful)
Well, Windows network admins? Say what you will about Windows, most of it's true. But lot's of serious companies use it, and some of them even hire smart people to admin their systems. Could be usful for something like that, maybe.
Re:That's all well and good (Score:2)
Re:That's all well and good (Score:2, Interesting)
One spyware infested crazy windows zombie machine botnet to rule them all!
Microsoft will continue to make unsecure software but this time with a way for the botnet controllers to actually do something with the botnets.
Re:That's all well and good (Score:3, Insightful)
Re:That's all well and good (Score:5, Insightful)
Lots of people are "bashing" this up agianst various Unix shells, but what does it matter? Windows needs something like this, period.
Re:That's all well and good (Score:3, Insightful)
Re:I don't get it. (Score:2)
I went poking around a bit further before the shit hit the fan, and found this little thingy called "CrashNot" [winnews.com] (dunno if it's genuine, www.crashnot.com doesn't work), the self-styled Counter-Slashdot. It's a chuckle.
But I like the idea of a Bugzilla for Microsoft products.
lol, personalized error ... (Score:4, Funny)
Is computing really becoming pervasive ?
At least it has a sense of humor 8)
'Server Error in '/' Application.
Runtime Error
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.
Details: To enable the details of this specific error message to be viewable on remote machines, please create a tag within a "web.config" configuration file located in the root directory of the current web application. This tag should then have its "mode" attribute set to "Off".
Notes: The current error page you are seeing can be replaced by a custom error page by modifying the "defaultRedirect" attribute of the application's configuration tag to point to a custom error page URL.
'