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
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.
" 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.
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.
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.
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.
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