Slashdot Mirror
Next-gen Windows Command Line Shell Now in Beta
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."
It is , I beleive, the fist object oriented shell.
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.
What's wrong with just running the Perl debugger, for an interactive shell? If the *nix shells were as limited in their reach into the OS APIs as the Windows commandline UIs have been, I'd use "perl -de 1" instead of bash or sh. As it is, I use that Perl shell for most commandline programming, especially for any data processing tasks. And a Perl shell has thousands of existing scripts, most of which work on Windows as well as any other platform, and are easily customized to script Windows apps. Even more, the Perl platform has lots of modules that embed programmable clients to Windows apps into scripts, and lots of scripts that bundle them together. Why not use old all-encompassing Perl, rather than the new, strictly limited Monad?
--
make install -not war
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.
Hitler's in the fridge.
Why is everyone immediately saying cygwin? Windows Services for Unix is the official release of ksh for Windows.
I'm sick of following my dreams - I'm just going to ask them where they're going and hook up with them later.
All of these little "tools", Microsoft is providing. Take a look at the samples for MSH and you will that the commands are heavily inspired by Unix.
.Net objects into mini applications with the full .NET framework available for use will be increadably useful.
/. junk filter)
/. junk filter)
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
http://brandonbloom.name
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.
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.
If Microsoft wasn't so arrogant / sufferring from 'not invented here' / needing to own every aspect of the OS so they can figure out new and innovative ways to exploit it once you rely on it, they could just include cygwin and a shell like bash.
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.
" And all of that will require processing power. All of those objects have to be converted each and every time they get passed. Even the conversion to text will take cycles."
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.
I rarely criticize things I don't care about.
If it ain't broken, don't fix it. Is there a *reason* why they used backslashes instead of forward slashes, historically? Or did they just do it for the sake of being different (which, in this case, is just a polite word for "incompatible")?
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.
quidquid latine dictum sit altum videtur.
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.
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.
Microsoft programmers should look up "second system effect": they keep making the same mistake again and again.
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.
and Microsoft has their own product, free download, called "SFU -- Services for Unix" that gives you a ksh shell and all the Un*x utilities." We actually stopped running BSD here and started running XP with SFU (and Cygwin) because it's a better desktop Un*x than the real thing.
Best Buy can have you arrested
Why do the unix zealots always dismiss ANY attempt to make the user experience more high-level / semantic-oriented (especially if it comes from Microsoft) ?
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>
He who has no
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.
Their bad (as in both -- nasty and foolish) ways of doing things are catching up with them all the time.
In Soviet Washington the swamp drains you.
I think this is going to be the next big bug. IE move over.
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.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
It's basically just a way to interact with your file system... Monad is a big step ahead for windows...
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.
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.
a shell scrip from 30 years ago MAY run on a current /bin/sh. i don't have my o'reilly unix in a nutshell with me right now (i keep it at work), but as i recall, there's a whole section titled 'obsolete commands'. these commands may not exist on a specific system. good luck getting your shell script to work when the commands within the script are invalid.
Wave upon wave of demented avengers March cheerfully out of obscurity into the dream
Also, the 4DOS wildcard rename feature has unfortunately not been adopted.
What no tabs?!?
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
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.In Soviet Washington the swamp drains you.