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."
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.
One Perl (Score:4, Interesting)
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: No Thanks (Score:4, Interesting)
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: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.
why not cygwin? (Score:1, Interesting)
Cygwin/bash is there, does everything people want out out of a shell, is under a license that would allow Microsoft to redistribute it, and Microsoft might get some positive points from the geek crowd.
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: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 with Windows. But those bundles are to sell computers. How come I don't see Windows upgrade licenses bundled with, say, an OpenOffice.org package, preconfigured to work right? Is there something in the Windows reseller license which requires that only Microsoft can bundle? Or just something in the Windows marketing agenda that prevents them from allowing those kinds of deals? Or merely apathy, and the monopoly mindset that prevents entrepreneurs from reselling Windows OS products bundled with non-MS apps?
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: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: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.
Re: No Thanks (Score:2, Interesting)
Drop the marketing jargon for a minute! (Score:1, Interesting)
Extracting the Microsoft-centric marketing jargon from your post (computing isn't a job, it's an experience!) so that I can get to the meat of the issue might be a bit difficult but here goes.
For about ten years since the dawn of Windows 95, Microsoft has spent a fortune downplaying the power of a CLI in favor of the all-powerful GUI. After all, why is it that cmd.exe and family are so incredibly anemic? 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. Everything must interact with the GUI, leaving only limited functionality to the shell.
So the upshot is that Microsoft is taking a step forward by moving a few steps back. Now that they're implementing a shell with something vaguely resembling real scripting, they have to somehow correct all of the marketing they have done over the years to mitigate the impact a lack of any decent shell in their operating systems. I know what will happen, too--Windows zealots will praise Microsoft for inventing the shell... never mind the fact that scriptable shells are older than I am.
Now for my next question. Why do you seem to believe this is innovative? The notion of a shell that interfaces with the system by way of core userland utilities (ps, ls, kill, et al) has been around since the inception of Unix. The fact that Microsoft has just now caught on to the usefulness of a powerful CLI is nothing innovative. Like the topmost post suggested, perhaps they are reinventing Unix--poorly. Perhaps, too, they should save themselves the headache and scrap the entire Windows source and start with something covered by a BSD license. They left the copyright in ftp.exe, after all--why not borrow the rest of the system?
Ultimately, I think MSH is just going to be a rotten hack, hyped up by Windows administrators who probably have no real understanding of what a powerful CLI can do. The shell is one thing--but what about all the other userland binaries that really make the shell useful? All the scriptable support in the world isn't going to save them no matter how bash-like it is--because without simple commands that can interact with running processes, the file system, and generally everything else (not those implemented within the shell, but ENTIRELY SEPARATE, which I don't think MS will do since they have a strange affinity for monolithic applications) what good is it really? Or is this innovation in the traditional Microsoft-marketing-department sense, where innovation is the capacity to strip all usefulness from an application to limit potential confusion, thereby increasing the end user's experience in a positive, fluffy-bunny environment?
</rant>
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: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: 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)
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 netsh, but they're not there yet. This is what monad is supposed to address.
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: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 scripting is because it pipelines objects rather than arbitrary strings. As has already been pointed out, you don't have to rely on awk or cut to parse out fields you care about (assuming they're even there -- you can't write a generic awk or cut script for various input, because the fields may be different across your different input streams). As well, because these are objects being pipelined, you can run methods on them directly.
Take the example of killing a certain process (let's ignore the killall app for now). In *nix shell scripting, you have to call ps, then parse the output with something like awk to match the right process name and retrieve the pid, and then run kill with that pid. You can't make the processing chain generic, because ps gives you different fields in different orders depending on the options you provide. In Monad, you call get-process (which is aliased as ps), filter the output with where-object (aliased as where) to find the $_.ProcessName -eq "your process", and call the resulting object's Kill method. In such a trivial example, there's no reason to make the processing chain generic, but you could write a function that takes a System.Diagnostics.Process object and does whatever it wants to it. Then you can use that function with anything that will give you a System.Diagnostics.Process object. It doesn't matter what the output looks like (by default, get-process displays Handles, Non-Paged Memory, Paged Memory, Working Set, Virtual Memory Size, CPU percentage, and Process Name, but there are many more properties and methods available to you), because you're getting the object, not the textual representation as you would in *nix.
You assume they're trying to reinvent *nix, rather than build something better. The core idea of pipelining objects may not be unique, but it's a very powerful concept and it's something that *nix simply doesn't have right now. You can dismiss this all you like, that's fine. I'd suggest you at least take some time and play with the beta first, so that you can make a truly informed opinion before dismissing it entirely.
As an example of the power of Monad, consider that a wget-like cmdlet has been written (get-url, not part of the basic set of cmdlets available with Monad, but it shouldn't be too hard to find the script on the beta newsgroups), in 40 lines of well-formatted script (ie, including empty lines, brackets on separate lines, etc -- compress it, and it's even less lines of code). It doesn't have all of the options of wget, but the capability is there, and it gives a good example of what you could do with a little bit of scripting. Now consider that Monad can easily transform output to xml, and you can use get-url, Monad's XML support, and a bit of pipelining to write an RSS reader in a trivially few lines of script. I'm not going to claim that python or perl couldn't do that just as well. That's not the point.
Re:30 years in computer years? About 1000 years (Score:2, Interesting)
A few very handy things I would like to see (Score:2, Interesting)
Also, the 4DOS wildcard rename feature has unfortunately not been adopted.
What no tabs?!?
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 people get better with Monad, it's expected that they'll switch to the Monad aliases for these functions (intuitively, get-alias for the list) for shorthand notation, or use Monad's autocompletion.
The other benefit of longer names is that within scripts, people can use the longer forms to make scripts easier to read and understand.
Leonard
Re:If it's good.... (Score:3, Interesting)
Sorry, this is just laughable. So, you, consider "D" to be easier to associate with a "cD-rom", than "/cdrom"? You are not even trying to justify the "A" for "floppy disk" :-)
The reaction of computer scientists should be your guide. These people tend to know answers to questions, which you don't know enough to even ask.
Oh, that's easy. You named it yourself: "for personal use". To ensure, it is available for personal use only you may only be allowed to run a single instance of it, unless you purchase the server license. Or it may not be available to telnet sessions. Or something bizarre like that. They better... With sh, csh (or whatever Unix shell rocks your boat) you can do anything. It may not be pretty, but it will work. Witness configure-scripts. With cmd.exe you can't even pass all of your own arguments down (there is no equivalent of "$@") -- forget about procedures, loops, etc. Oh, I'm sure, there are plenty of smart individuals working for Microsoft. However, the firm's organization and its dirty unatoned past (and, likely, present) will continue to weight on the firm's products -- and their reputation -- for some time... And these -- the reputation and perception -- are the subject of the thread.