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

30 of 668 comments (clear)

  1. Here's a Screenshot by blackmonday · · Score: 5, Funny

    Here's a Screenshot:

    Microsoft Windows XP [Version 5.1.2600]
    (C) Copyright 1985-2001 Microsoft Corp.

    C:\>


  2. This is what Microsoft has been "fighting" for! by Anonymous Coward · · Score: 5, Funny

    A command line. How innovative!

  3. This is fantastic news. by Anonymous Coward · · Score: 4, Funny

    Windows gets more and more like Linix every day. At this rate, I soon won't be able to cut-n-paste between applications! Bring it on. Have they ported xcdplayer yet?

  4. Monad? by Deal-a-Neil · · Score: 5, Funny

    What kind of name is that? Sounds like a command shell that had one testicle removed.

  5. monad by yakumo.unr · · Score: 5, Interesting

    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.

  6. Re: No Thanks by torpor · · Score: 5, Informative

    Ok, but does bash or ksh run on windows? This is for their own OS, not unix.


    Of course it does, silly.

    --
    ; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
  7. I guess the site's running it .... by SourKAT · · Score: 5, Funny

    ... doesn't have a web interface...

    Visitors We are sorry but this site is experiencing difficulties at this time. Please return shortly! Thank you for your patience. Webmaster - please contact support as soon as possible.
  8. First impressions by Alioth · · Score: 4, Insightful

    I've had it since yesterday.

    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.

    1. Re:First impressions by Des+Herriott · · Score: 5, Insightful

      "get-process" is far more intuitive than "ps"

      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.

    2. Re:First impressions by slavemowgli · · Score: 4, Insightful

      That, frankly, is rubbish. Someone who doesn't know about the commands and what they do will have to learn their names anyway; it doesn't matter, for example, whether you have to remember "get-process" or "ps". In fact, it might be easier to remember "ps", as it is shorter and more concise.

      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.

      --
      quidquid latine dictum sit altum videtur.
    3. Re:First impressions by Ravatar · · Score: 4, Informative
      Then use ps, it's a built-in alias for get-process.
      MSH>help ps

      NAME
      get-process

      SYNOPSIS
      get-process -Id id | -ProcessName name

      SHORT DESCRIPTION
      Lists processes currently running

      DETAILED DESCRIPTION

      -Id id
      [int[]]
      [pipeline input allowed]
      Comma separated list of process identifiers that specify the processes to ge
      t

      -ProcessName name
      [string[]]
      [pipeline input allowed]
      Comma separated list of process names that specify the processes to get

      -Exclude name
      [ArrayList]
      Comma separated list of process names to be excluded from the output.

      ---
      The Command will enumerate processes from local machine and output System.Di
      agnostics.Process object(s). The command will write the process object to th
      e output pipeline one by one. The Command will take parameters like ID(Proce
      ss Identifier) or Process Name from command line. The Command will return th
      e corresponding system.diagnostics.process for the supplied ID or ProcessNam
      e parameter(s).

      This command also supports the ubiquitous parameters:
      -Debug (-db), -ErrorAction (-ea), -ErrorVariable (-ev)
      -OutputBuffer (-ob), -OutputVariable (-ov), and -Verbose (-vb)

      NOTES
      Exclude only works for process name.

      EXAMPLES
      get-process
      Returns all running processes

      get-process svc*
      Returns all processes with names starting with svc

      PROVIDER SPECIFIC

      DYNAMIC PARAMETERS
  9. whoosh! by lheal · · Score: 5, Insightful

    That was the sound of the point, flying past Microsoft's Collective brain.

    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.

    --
    Raise your children as if you were teaching them to raise your grandchildren, because you are.
    1. Re:whoosh! by SnprBoB86 · · Score: 4, Interesting

      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.

      This tools are "commandlets." Being able to pipe .Net objects into mini applications with the full .NET framework available for use will be increadably useful.

      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 /. junk filter)

      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 /. junk filter)

      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
    2. Re:whoosh! by ArbitraryConstant · · Score: 4, Interesting

      " 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.
    3. Re:whoosh! by Eudial · · Score: 4, Insightful

      $ ps vOr

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

      --
      GAAH! MY PRINTER IS ON FIRE!!! PUT IT OUT! PUT IT OUT!
  10. Re: No Thanks by lazy_arabica · · Score: 5, Insightful

    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) ? I am a Unix-user, but I'm also very interested in MSH, some of its features sound really innovative and powerful. I'll probably stick with bash too though, until Unix becomes deprecated (because I don't think it will ever evolve, since so many people, like you, think the perfection has been invented 30 years ago.)

  11. Or you could just download the release-quality one by mcc · · Score: 4, Funny
  12. Re: No Thanks by grasshoppa · · Score: 4, Insightful

    Yes, cygwin makes common Unix shells available on windows, but it's just a CLI. It doesn't interact with the rest of windows, the registry, other user space apps, etc. 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. You use other programs to do the work, bash is simply an interface to the file system. And a damn elegant one at that.

    --
    Mod me down with all of your hatred and your journey towards the dark side will be complete!
  13. Re:That's all well and good by CaroKann · · Score: 5, Insightful

    A windows shell, without the various limitations of the DOS shell, would be very useful in more ways than I can count. For example, DOS .bat files are still used a lot, especially in cases where you want to run an application, like a Java based program, with it's own system environment setup.

    Lots of people are "bashing" this up agianst various Unix shells, but what does it matter? Windows needs something like this, period.

  14. They tried this before by infonography · · Score: 5, Funny

    I didn't write this but I wish I had been there.

    " 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/quickie s.html

    --
    Sorry about the writing. Robot fingers, you know? Cliff Steele in DOOM PATROL #23
  15. Re: No Thanks by SilverspurG · · Score: 4, Insightful
    To me, Monad is an exciting effort to try to reinvent the command line.
    The biggest hurdle for the Monad shell is that Microsoft has painted themselves into a corner. The vast majority of software running on a Windows platform was not written with command line operability or scripting in mind.

    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.
    --
    fast as fast can be. you'll never catch me.
  16. Ok, ok... fun's over--seriously now... by nightcrawler.36 · · Score: 4, Insightful

    When I first read this, I too thought MS was just retooling some form of CMD to compete with the new-found craze in command lines. But then I read about it on Wikipedia.org. It's considerably more than most of you are thinking. I'm not going to point out what it does here, go read about it(if you don't know what it is.). But how much of this is Microsoft bashing and how much of this is a legitimate analysis of the quality of computer user tools? I think we're seeing a world where things are starting to settle in to what they should be. Windows are going to be desktop machines, *nix are going to run servers(not IIS) and Macs will continue to win the hearts and minds of artists, universities and affluent kids. MS is not reinventing UNIX. They're simply providing *NIX-like tool for "Windows" developers'. It's called competition and it's good for us. It gives me yet another option to choose from. Welcome it! you don't have to use it if you don't like it.

    --
    - nightcrawler "Reality is an illusion, albeit a ver persistent one..." -A.Einstein
  17. Re: No Thanks by Curtman · · Score: 5, Funny

    Why do the unix zealots always dismiss...

    Because we're Unix zealots dumb ass. Get with the program.

  18. Re: No Thanks (not UNIX, VMS!) by Ingolfke · · Score: 4, Informative

    Those who do not understand Unix are condemned to reinvent it, poorly

    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 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 .NET class derived from our base class and tag it with a NOUN and VERB. The properties of that class become PARAMETERS.

  19. Re:If it's good.... by IamTheRealMike · · Score: 4, Interesting
    That would be hard, MSH leverages .NET quite extensively. You might see a Mono Shell, or a Python Shell using the same concepts though.

    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.

  20. 30 years in computer years? About 1000 years by Moderation+abuser · · Score: 4, Funny

    The fact that the Unix command line has stood the test of time when virtually everything else has been redesigned and redesigned and redesigned is an amazing testament to the thinking which went into it.

    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.

    --
    Government of the people, by corporate executives, for corporate profits.
  21. what can UNIX learn from this? by ArbitraryConstant · · Score: 4, Insightful

    I don't think many of us care that the command names are a little hard to remember. I have just as much trouble remembering stuff from APIs with nice names like Java.

    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.

    --
    I rarely criticize things I don't care about.
  22. Re: No Thanks by NickFortune · · Score: 4, Insightful
    Well, it might have something to do with the Windows zealots have sneered at all things *nix for years on end. That does tend to bring about a certain amount of crowing when Redmond, years after trumphantly declaring a technology obsolete, copies it amidst much fanfare and proclaims it to be the Way Forward.

    Yep, that'd do it for me :)

    --
    Don't let THEM immanentize the Eschaton!
  23. Quick Tour of Monad by SteveX · · Score: 4, Interesting
    I wrote a short article on Monad as well.

    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.

  24. Re:Drop the marketing jargon for a minute! by moonbender · · Score: 4, Informative
    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? [...] Everything must interact with the GUI, leaving only limited functionality to the shell.

    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 /system32 that I never ever came close to using.
    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.
    C:\Documents and Settings\ms>taskkill
    ERROR: Invalid Syntax. Neither /FI nor /PID nor /IM are specified.
    Type "TASKKILL /?" for usage.
    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. ;)
    --
    Switch back to Slashdot's D1 system.