Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Microsoft IT

A Guided Tour of the Microsoft Command Shell 519

jpkunst writes "Ryan Paul at Ars Technica provides an in-depth, 13 page review of the new Microsoft Command Shell (Monad). (The beta release can be downloaded for free from Microsoft.) From the conclusion: 'Despite my initial skepticism, I am deeply impressed with MSH technology, and I am legitimately excited about the future of the Windows command line.'"
This discussion has been archived. No new comments can be posted.

A Guided Tour of the Microsoft Command Shell

Comments Filter:
  • by Anonymous Coward
    Everyone knows that "msh" really stands for "Microsoft Hell".
  • by mi ( 197448 ) <slashdot-2017q4@virtual-estates.net> on Monday October 24, 2005 @07:44AM (#13862974) Homepage Journal
    The "robust commercial applications and standard graphical utilities" are, indeed, in much need of reinvention. Oops.

    And what's with the "unleash" keyword? Do these people really think in terms, that glossy ads use to compare the advertised products with animals?

    • Not only that, but consider the portion that says 'The Windows community is a universe of uniformity [...] and standard graphical utilities.'

      Indeed, we are seeing that that is not the case. Microsoft has gone out of their way to drastically alter their GUI, such that it looks nothing like the XP GUI, and thus nothing like the older GUI before that. Hardly a show of uniformity, if I do say so myself.

      • by Jugalator ( 259273 ) on Monday October 24, 2005 @08:04AM (#13863114) Journal
        Are you talking about the new Vista UI?

        In that case, that's a visual style that's changing only the aspects of the UI Windows XP changed. Windows border styles and new flashy button hover effects, etc. Think of it as a different theme/skin, not a way for them to change the UI design guidelines. "OK" will still always be followed by "Cancel", group boxes will still group UI elements with a relation, menus will still be part of the applications and not the dsektop, combo boxes will still be recommended only in "little space" situations, and so on. :-)

        Actually, Microsoft has released preliminary design guidelines for Vista [microsoft.com], and I was surprised to see how much can be directly applied, and is even recommended to be applied like that, to Windows XP.

        Also, even in Windows Vista, just like in XP, can you still apply the Windows 2000 look & feel via a flip of a switch. That if anything should show that all they're really doing are mostly just applying new skins to sell their product, and not coming up with new guidelines that indeed would alienate their broad customer base. If I'm at some user that have applied some simple settings, I often lose myself in thinking I'm working on a Windows 2000 workstation when I'm in reality on XP.
        • by cnelzie ( 451984 ) on Monday October 24, 2005 @08:19AM (#13863188) Homepage
          There's far more of a difference between Windows XP and Windows 2000, then just a graphical skin. The methods for accessing a handful of configuration settings windows has altered and in some cases, those configuration modules have changed significantly on their own.

              To say that there won't be changes beyond simple "Graphical skins" simply does not hold with the historical perspective of the sweeping changes with each major iteration of Windows.

              Windows 3.11 to Windows 95 to Windows 98 to WindowsMe, there were underlying configuration changes that made learning the "new" OS important.

              Windows NT 3.5 to Windows NT 4.0 to Windows 2000 to Windows XP also included significant configuration setting alterations that were far more drastic then the "Consumer Level" Windows Operating Systems.
        • by SilentChris ( 452960 ) on Monday October 24, 2005 @10:04AM (#13863905) Homepage
          I've studied the new UI quite a bit, and you, sir, are clueless.

          Are they keeping things like "OK" and "Cancel? Yes. Are you able to change the look back to Windows 2000 (well, sort of). Yes. They do things like this so people don't need to totally retrain.

          Is the user interface anything like Windows XP, under the hood? No. God no.

          The entire thing has been rewritten from the ground up. Everything is a .NET object, everything inherits from another object. The entire thing is texture based, like OS X.

          What this means is they CAN make drastic changes down the road by simply changing a few objects. Everything will inherit down. Ever notice that buttons can be totally dissimilar from one app to the next, and all MS has been able to do is (for example) but a blue highlight around them? That's because the UI has been so cripped.

          The new UI is simple, beautiful and brilliant. Is it completely different than Windows XP? No. It's not intended to be. The goal, like .NET, is to have a framework to build off for the future. Like .NET, too, the new UI is well-written. I've been programming for it for half a year now and it blows Windows XP out of the water. It even tops OS X in a few areas.
      • by everphilski ( 877346 ) on Monday October 24, 2005 @09:05AM (#13863490) Journal
        The colors may have changed but the patterns are the same. The start button is at the bottom left hand corner. The taskbar spans the entire bottom of the screen. The three buttons on the upper right of any window are minimize, toggle fullscreen/windowed, and exit, respectively, in that order.

        That is what uniformity is. Changing colors / visual schema is not uniformity. That's like saying a green car is not uniform to a blue car. You can still drive it with the knowlege you learned in drivers ed.

        -everphilski-
  • by Anonymous Coward on Monday October 24, 2005 @07:45AM (#13862979)
    We must have a working implimentation of this shell in Gnome immediately.

    I propose we call it Gonad.
    It will be the dogs bollocks.
    • Title says it all
    • by Bobke ( 653185 ) on Monday October 24, 2005 @09:53AM (#13863824)
      While you are trying to be funny, you are correct,
      unix does need a shell like monad I'm afraid (hence ac)

      What monad will offer is something like

      >ls -l | head -n 10 | sort size | excel

      They are piping objects, we would need to do a lot of parsing to achief the same effect.

      Someone really needs to write a new shell for unix and abstract the unix system, by giving it knowledge of the common unix tools (parsing the output for the user), like ps, ls, sed, etc.

      Want to be famous ?
      Here is your idea.

      • What monad will offer is something like

        >ls -l | head -n 10 | sort size | excel

        They are piping objects, we would need to do a lot of parsing to achief the same effect.
        Just do : ls -l | sort | head -10 | tr -s " " "\t" > dir.txt; gnumeric dir.txt & After all, if you're going to be manipulating it in a spreadsheet, you probably want to save it in a file somewhere anyway, right?
        • Just do : ls -l | sort | head -10 | tr -s " " "\t" > dir.txt; gnumeric dir.txt & After all, if you're going to be manipulating it in a spreadsheet, you probably want to save it in a file somewhere anyway, right?

          Kick in the *NIX fanboi defense reflex: Offer a half-baked parallel and insist that any deficiencies are things you didn't need or shouldn't be doing in the first place.

  • impressive (Score:4, Insightful)

    by Anonymous Coward on Monday October 24, 2005 @07:45AM (#13862984)
    Indeed, that MSH demo is impressive and all, but python is great too. System-wide integration? Big fucking deal:
    >>> import kudzu
    >>> kudzu.probe(kudzu.CLASS_HD, kudzu.BUS_IDE, kudzu.PROBE_ALL)
    [Desc: MAXTOR 6L040J2 Driver: ignore
    Device: hda , Desc: ST360021A
    Driver: ignore Device: hdc
    , Desc: Maxtor 6Y120P0 Driver: ignore
    Device: hde ]

    etc, and python is easily expandible to cover ALL the system. What makes MSH rock is that it's a python-like programming languaje PLUS a user-oriented (user=administrator) shell like bash. In linux we're used to program scripts with python, then pass the data through pipes to bash to do something with it. Crappy. When you have to do things like "command | cut -d ' ' -f 3 | cut -d ':' -f 1" to get some data, you know something is WRONG.

    The cool thing about MSH that its a SUBSTITUTE to bash/cmd.exe, not a "complement" like python is. Is not that bash or python are bad, but bash-like shells are 30-years-old unchanged technology. Fortunately, there're people writing user-oriented python-based shells, like http://ipython.scipy.org/ [scipy.org]
    • Re:impressive (Score:3, Insightful)

      by Anonymous Coward
      When you have to do things like "command | cut -d ' ' -f 3 | cut -d ':' -f 1" to get some data, you know something is WRONG.
      Yes. Either your command is wrong (it should do that formatting as its output) or you should have used [g]awk instead of cut.
    • Re:impressive (Score:5, Insightful)

      by NickFortune ( 613926 ) on Monday October 24, 2005 @08:05AM (#13863121) Homepage Journal
      When you have to do things like "command | cut -d ' ' -f 3 | cut -d ':' -f 1" to get some data, you know something is WRONG.

      Agreed. In this case it's the coder, who should really have enough nous to print the data in the format in which he intends to use it. That's hardly rocket science, is it?

      Of course, if you didn't write the python script and don't have the time and/or skill to hack it, you might nd up using cut and the like to get the data in the format you need. The cool think about that is that it's possible. I don't know if the same can be said under MSH, but it seems unlikely - the focus of Monad seems to be .NET integration, not a stream based filtering command line environment.

      Then again, maybe you didn't even write the wrapper script and don't understand anything. If so you can always troll slashdot as an AC and get some astroturfing in.

      • "Of course, if you didn't write the python script and don't have the time and/or skill to hack it, you might nd up using cut and the like to get the data in the format you need. The cool think about that is that it's possible. I don't know if the same can be said under MSH, but it seems unlikely"

        Did you even open the article? MSH is significantly more powerful than cut. Bash can only dream of the features it has.

        • Point me at the bit where you thought I said "MSH is less powerful than cut". Then we can talk.
        • Re:impressive (Score:5, Interesting)

          by SilverspurG ( 844751 ) * on Monday October 24, 2005 @09:46AM (#13863771) Homepage Journal
          I'm reading the article and, you know, I'm just not seeing anything in here but a horribly tortured object oriented syntax and a reexpression of MS' nightmarish implementation of the common "--help". I did, however, find this admonishment:
          One of the major frustrations of MSH is the lack of support for piped input in other Windows applications. I can't pipe my HTML content into a new instance of Internet Explorer and I can't pipe my CSV content directly into a new instance of Excel.
          Considering the decades of command line functionality which sh type shells have, apparently MSH is only dreaming of what BASH can do.

          Followed closely by:
          I sincerely hope that the final release of MSH features an entire collection of convert and export commands for a broader variety of formats. Sources inside Microsoft tell us that MSH users will probably use COM and ActiveX to interface with major Windows applications.
          It's a security nightmare waiting to happen. If people think BASH viruses are a potential problem then imagine the full horrors of ActiveX with access to a system shell. At least Mozilla exploits don't lead to "rm -rf /" or malware stuffed all over the system.
          • Re:impressive (Score:4, Insightful)

            by EvilNTUser ( 573674 ) on Monday October 24, 2005 @01:39PM (#13865643)

            "I'm just not seeing anything in here but a horribly tortured object oriented syntax and a reexpression of MS' nightmarish implementation of the common "--help"."

            The object oriented stuff provides extra features. You can still alias all the old stuff to the usual commands, and it apparently does so by default.

            "Considering the decades of command line functionality which sh type shells have, apparently MSH is only dreaming of what BASH can do."

            Please explain again how you think it's the shell's fault that other applications don't support its features. Oh and btw, `echo 'html-stuff' | firefox` results in a blank browser window.

  • by CyricZ ( 887944 ) on Monday October 24, 2005 @07:45AM (#13862985)
    Has any project been started to provide an open source clone, similar to what the Mono Project has done with .NET?

    • Well, it's not a clone, but Python provides some pretty fine functionality. I'm not at all sure that msh is an improvement on Python...
      • by zootm ( 850416 )

        They're similar, but not really the same. Python isn't geared towards being a command shell (although obviously after importing the right packages you can use it as one).

    • by LnxAddct ( 679316 ) <sgk25@drexel.edu> on Monday October 24, 2005 @09:49AM (#13863796)
      There are already quite a few shells in unix that follow a similar paradigm. Python's default shell comes pretty close, but there are off shoots of it that provide functionality designed to be used as a command shell. MSH is pretty much an interactive ruby shell or python shell designed to run regular commands and treat files like objects (which is as simple as defining a class that can interpret the file information and give it methods like .get_extension) The real key here is that I belive everything is treated as an object. With minor modifications to the python shell and maybe an additional class or two you would have the exact same functionality. You see... there is a reason though that noone has done this. System administrators should not have to learn the concepts of object orientation just to do their job. They are not programmers. Its bad enough when programmers design GUIs because they cater to programmers and not typical users. Monad caters to programmers and not system administrators. Most unix sys admin I know do know how to script in something like perl or python, but most windows admin are point and click or they can type a few commands into a file and rename it to .bat to run it. The monad shell has some great ideas for a shell used by and for programmers, but honestly it isn't a sys admins job to understand programming or programming paradigms. Let admins use simple bash like commands, even if it may not be the cleanest way, conceptually it is often easier, and let programmers script their way out of any hole they want.
      Regards,
      Steve
  • Some Wise Man Said (Score:4, Insightful)

    by R55 ( 601001 ) <raviNO@SPAMindia.com> on Monday October 24, 2005 @07:46AM (#13862987)
    Those who do not understand Unix are condemned to reinvent it, poorly.<br>
    -- Henry Spencer<br>
    Usenet signature, November 1987
  • by zaguar ( 881743 ) on Monday October 24, 2005 @07:47AM (#13862993)
    The new google shell: Gonad

    It's nuts

  • Perhaps the Windows shell has finally reached the levels of goodness of that old shell, whatchyacallit. DOS, I think it was.

    I forget what company it was that made that, but I'm sure if they were still around, they'd be doing amazing things. We can certainly agree that they'd without a doubt have a command line that would blow Microsoft's right out of the water.
  • by SomeoneGotMyNick ( 200685 ) on Monday October 24, 2005 @07:49AM (#13863007) Journal
    Backslashdot

    Specializing in Unix bashing (somewhat of an ironic statement)
  • Jeez... (Score:5, Funny)

    by gowen ( 141411 ) <gwowen@gmail.com> on Monday October 24, 2005 @07:49AM (#13863009) Homepage Journal
    the text-based shell is the nexus of computational control and the point at which proper articulation of will can transform commands into consequences Which leads to two questions : who wrote this shit, and were they getting paid per syllable?
    • So... he's saying, "The shell is where you type things to make your computer do stuff"? Gee. Thanks.
    • Re:Jeez... (Score:4, Funny)

      by revery ( 456516 ) <charles@c[ ].net ['ac2' in gap]> on Monday October 24, 2005 @08:35AM (#13863290) Homepage
      Which leads to two questions : who wrote this shit, and were they getting paid per syllable?

      It was the same person that wrote the dialogue for research breakthroughs in Alpha Centauri.

      the text-based shell is the nexus of computational control and the point at which proper articulation of will can transform commands into consequences
      - Col. Corazon Santiago Spartan Programmer's Manual
      • Re:Jeez... (Score:5, Funny)

        by ikkonoishi ( 674762 ) on Monday October 24, 2005 @09:10AM (#13863520) Journal
        Ah come on those things were great.

        My favorite.


        We are all aware that the senses can be deceived, the eyes fooled.
        But how can we be sure our senses are not being deceived at any
        particular time, or even all the time? Might I just be a brain in
        a tank somewhere, tricked all my life into believing in the events
        of this world by some insane computer? And does my life gain or lose
        meaning based on my reaction to such solipsism?
        ^
        ^ -- Project PYRRHO, Specimen 46, Vat 7
        ^ Activity Recorded M.Y. 2302.22467
        ^ TERMINATION OF SPECIMEN ADVISED
  • Slightly Wrong... (Score:2, Informative)

    by Anonymous Coward
    Taken from "system requirements"Requires the .NET Framework Version 2.0 Redistributable Package Beta 2 (x86) (see Related Downloads below).
    Note that the "Supporting Operating Systems" list above is slightly wrong: the release is supported on Windows XP SP2, not Windows XP Embedded SP2.


    Microsoft can't even get its own system requirements right... I someone expects a robust security infrastructure...
  • On The Pipe (Score:5, Interesting)

    by Murmer ( 96505 ) on Monday October 24, 2005 @07:57AM (#13863062) Homepage
    It's worth mentioning here that the real strength of the pipe is not "what you can pipe", but "what you can pipe things from, and to", and the fact that you can daisy-chain them together as far as you like. There are literally thousands, maybe tens of thousands of little tools and widgets that you can pipe information into and out of to achieve various effects. Regardless of what new things the MSH pipe can do, the unix world has a significantly larger toolbox.
    • The fact that UNIX has a larger toolbox is not so relevant when you consider that this is still pre-release — if it's a competent shell, it'll have equivalents to most of the useful functions available to the *nix world before very long.

      • Re:On The Pipe (Score:3, Interesting)

        by /ASCII ( 86998 )
        True. But on the other hand it is much harder to write simple general purpose filters for generic objects than for text data. There are quite a lot of general purpose tools in Unix, like grep, sed, tail, etc. that can operate on almost any form of data, whereas MSH tools need to operate on objects, which is quite a bit harder. The potential for ultimate coolness is there, but if the implementation is lacking, MSH will be useless.
        • I agree, to some degree, but if you look at how they've implemented object orientation on the command line, it's certainly consistent. On one hand it's easier to apply generic operations to strings, but then there's only so much one can achieve when treating everything as a string.

          As a consequence of what you mention, though, looking at the commands it seems as though there are slightly more "basic building block" commands than in the *nix world, with slightly more specific purposes. I'm not convinced it's

        • Re:On The Pipe (Score:3, Insightful)

          by Haeleth ( 414428 )
          it is much harder to write simple general purpose filters for generic objects than for text data. There are quite a lot of general purpose tools in Unix, like grep, sed, tail, etc. that can operate on almost any form of data, whereas MSH tools need to operate on objects, which is quite a bit harder.

          If all objects have methods to serialise them to strings - and it doesn't seem unreasonable to assume that they will - then whenever you're fed an object you don't know about, you can access it as a string. At w
  • by CastrTroy ( 595695 ) on Monday October 24, 2005 @07:58AM (#13863070)
    A shell is nice but, can you change all the settings from the command line? The fact that most of your settings are stored in the registry, makes things a lot harder to do from the command line. Sure you could probably change a key or two if you needed to. But you'd probably have to know the exact location. Browsing the settings, to find the key you want, would be a lot harder. Can you install most programs from the command line, and manage all your installed software from the command line. I like the fact that in Linux, most base system stuff is designed so that it can be done by the command line, first and foremost, I like the fact that Linux stores all the settings in text files. This means that you can change the setting with any text editor of your choice. Also, there is a huge library of tools available at the command line. Not just stuff that was thought up by the people who made your command line (bash, csh, zsh), but also anybody else who made just about any other utility.
    • by alecks ( 473298 ) on Monday October 24, 2005 @09:27AM (#13863636) Homepage
      Yes, you can. you can change registry settings from the command line. Yes, you have to know the exact location, but that's like saying 'you have to know how to use a computer to use a computer'.
      Yes you can install ALL programs from the command line... expecially the ones designed to use the standard windows installer (.MSI). It has some powerful commandline options, which are universal across all apps that use it. Search for msiexec.exe
      You can do everything and anything from the command line. WSH/WMI add a great deal more functionality as well, and you can still keep it at the command line.
    • by TummyX ( 84871 ) on Monday October 24, 2005 @09:33AM (#13863681)
      If you had read the article you would have discovered that MSH includes a managed virtualfilesystem-like provider for the registry that allows you to navigate the registry and read/write settings.
    • by gnovos ( 447128 ) <gnovos@chipped . n et> on Monday October 24, 2005 @11:57AM (#13864851) Homepage Journal
      HARD? What's so hard about:

      echo 0x0001429 | regfxr32 \g \l \b \"/virtual registry hive sftwre/000003/Local Users and Directories/software/Microsoft/user/holebert/alpha MIX4_2_07/0x8827832fa777e9182/settings/color\"
    • by WebCowboy ( 196209 ) on Monday October 24, 2005 @12:11PM (#13864959)
      A shell is nice but, can you change all the settings from the command line? The fact that most of your settings are stored in the registry, makes things a lot harder to do from the command line.

      Very valid concern regarding the Windows platform. You can indeed do most of what you need to do in Windows through a command line if you are a guru, however without Monad Windows command-line capabilities are extremely weak. Regedit can be used at the command line, however it is quite cumbersome--especially if you must browse the registry. The whole concept of the registry puzzles me actually--here is this obsfucated, hidden, monolithic configuration file that holds all this important system information and if it were to be corrupted it could potentially make the machine unusable. In order to manage it, MS spent the time to greate this regedit program to decode the registry and present it as...a filesystem-like tree structure. Good Lord, what the hell for? When MS was addressing the problem of .ini files ten years ago what happened to the KISS principle? They did a good thing when they invented the "Program Files" folder and instructed developers to install their program folders there. Why didn't they just make another directory called "System Settings" and specify a standard .ini file format at that point?

      If that sounds almost like a UN*X /etc directory then you'd be right--it's worked for aeons so why complicate things by re-inventing the wheel? The concept was sound it just needed fine tuning. Then MS wouldn't have had to make a special utility to manage system settings at all if it didn't want to.

      Fortunately MS has seen the light and it appears that they are trying to quietly re-invent Windows in the image of UN*X. Of course, they won't admit their mistakes and copy UN*X/Linux design outright--they are re-architecting Windows using the same concepts but their own dialects (and in some cases they are making improvements to those concepts). This means that Microsoft can claim to be "innovating" instead of fixing bad design decisions. Some examples of the direction MS is going:

      * Monad--an "object oriented shell" that brings a modern image to a very old idea. MS is acknoledging that the command line really IS a good adia and not obsolete, and that it was a mistake to neglect its command line shell. The object oriented approach and consistent interface is a modern solution to a problem originally solved in part with pipes in UN*X. Python provides an object-oriented shell on that platform now--but MS just polished the idea a bit and made the whole shell solution more unified.

      * XML-based config files. You won't ever hear Microsoft admit it, but the system registry is a flawed concept and the implementation in Windows was so bad it was a significant source of relaibility and security problems. If you look hard enough in MSDN literature and in blogs, you will find that MS is quietly pushing developers to eliminate their dependency on the registry in favour of .config XML files stored in the same folder as the application's executable. MS is deprecating any tools they had to deal with the registry in favour of this method of managing system settings.

      * Microsoft has been slowly expanding developer options for creating GUI-less applications (services and console apps). Prior to VS.NET (right up to version 6) to do so required using C or employing awful, unsupported hacks (anyone who has tried writing a VB6 console app or service knows what I'm talking about--the required hooks into low-level Windows APIs make the result so ugly you are best advised to give up and use C anyways). Now MS has the CLR and .NET libraries that make it much easier to do GUIless application developent and allow you to do it in many different languages (although if you look at VB.NET it is more of a CLR dialect than a distinct language anymore--esentially C# without semicolons and a handful of BASIC
  • by Dekortage ( 697532 ) on Monday October 24, 2005 @07:59AM (#13863078) Homepage

    Just a few days ago, there was another article on Slashdot [slashdot.org] about how Ballmer wants to "storm Linux." If they can convince *nix people that Windows has a powerful CLI, this will do much to suck them in... it is the "eye candy" for true geeks.

    The article author starts to say this himself: My biggest frustration with MSH is the low quality of the actual shell interface. On my Linux system, I am extremely dependent on line editing keyboard shortcuts that simplify manipulation and alteration of command line input. MSH has very few line editing shortcuts, and extremely limited support for tab completion.

    And I remember when CP/M [sysun.com] was all the rage... *sigh*

    • I agree. Sure a good syntax is vital for a shell, but it seems to me they have completely forgotten that a shell needs a good UI as well. I would have expected them to implement things like command-specific tab-completions, syntax highlighting, clipboard intergration, etc., but I guess MSH is really only meant for scripting, not interactive use. Shameless plug: If you're running Unix, you can try out fish [no-ip.org], a shell which features all the above UI niceties as well as a cleaned up shell syntax.
  • Marketing sucks (Score:3, Insightful)

    by Xarius ( 691264 ) on Monday October 24, 2005 @08:00AM (#13863094) Homepage
    Yet again Microsoft takes an age-old technology, like scalable icons or transparency, and turns it into the best thing since sliced bread? Shouldn't they be condemned for leaving it this long to release a tool as powerful as this, instead of praised?

    The best I can say is "It's about damn time".
    • Uh, if you wanted to condemn them for not having a tool like this, you should already have done so. Once they come out with it, you shouldn't suddenly start bitching that they are late.

      Then again, you are probably one of those /. trolls who hate anything MS does ever and will not be happy even if they do something you want them to do.

  • by chendo ( 678767 )
    When I saw this line:

    msh> "this is a test".split(" ")

    I immediately thought "Python" (although I realise this may apply to other languages as well).

    Seriously... I can see a Python-based shell that can do what MSH can (named 'pash', possibly?). I respect the SQL syntax used and it could be useful, although I dislike the idea of using |s for this (no real reason... it just looks/feels wrong).

    Another downside (for me) is that it's too verbose. I'm used to short commands like 'cat' instead of somethin

    • I'm not that familiar with python, but the split command sure looks like ruby to me http://www.ruby-doc.org/core/classes/String.html#M 001405 [ruby-doc.org]
    • I've seen a variety of language-based shells crop up in the past. For some reason the lisp/guile based one sticks out in my memory. They usually fade to obscurity pretty quickly as people realize that they can get their work done much more concisely with one of the older shells. It never usually seems like all that big a deal anyway, since bash doesn't restrict you to bash -- you can always throw together a python or ruby script to do some major chunk of work if you want to.

      OS/2 had a pretty decent langua

  • ..C# (Score:5, Insightful)

    by jkind ( 922585 ) on Monday October 24, 2005 @08:02AM (#13863109) Homepage
    Well it looks like C# will be alive and well for some time to come. This article definitely had the feel of Jesse Liberty's Programming C# OReilly book.
    " MSH has a number of unique features that make it easy for users to leverage .NET technology at the command line. Type casting is an easy way to transform a simple core type into a .NET instance or another core type. To cast an instance into another type, simply place the name of the desired type in brackets right in front of the instance. You can change a string into a number with an int cast:
    msh> [int]"5" + 5
    10
    "
    is basically the section from the book on boxing and unboxing. Anyway, as a C# developer, it's great to see the language isn't dying..
  • The why (Score:3, Interesting)

    by zxm ( 669276 ) on Monday October 24, 2005 @08:06AM (#13863122) Homepage Journal
    Finally, MS has understood that a powerful shell language is necessary for a modern operating system.

    For a long time, it has been proud of his UI technologies, and thought the UNIX shells are too complicated to most people. As for the genernal people, it's right indeed; but it's not true for those developers that want to perform some customized tasks through some kind of relatively easy method.

    The real problem is, Linux has been attracted more and more developers, it's absolutely dangerours to the Windows future. it must do something to change this situation, as a part of a series of actions according its plan.

  • >Unlike Linux command-line utilities, which contain their own argument parsers and output
    >format mechanisms, MSH commands (called Cmdlets) all inherit a single base class, which
    >ensures that all commands expose the same methods, parse arguments the same way

    That's not entirely true about Unix (Linux): first, it omits to mention that Unix shells traditionally expand pattern matches in the given arguments, and match the command to an executable, before passing the arguments to that executable; and, se
  • doing it for? (Score:5, Insightful)

    by sgt scrub ( 869860 ) <saintium AT yahoo DOT com> on Monday October 24, 2005 @08:22AM (#13863197)
    I didn't get very far into the article before they got to the "we do things for you" part. Maybe I'm alone in this belief but I absolutely hate it when a language/shell/application will do things for me.
    For instance (from the article):

    MSH features the typical data types found in most other modern languages: strings, integers, arrays, and hash tables. When you enter any of those kinds of values at the command line, MSH will echo them back.
    msh> "blah"
    blah
    msh> 5
    5
    By comparison, in the Bash shell, expressions are always treated as commands and the echo command must be called explicitly if the user wants to display a value at the command line.


    If I want an echo statement I WILL TYPE echo! I don't want the software to ASSUME (make and ass out of me) if I make a typo!
    • Re:doing it for? (Score:3, Insightful)

      by fzammett ( 255288 )
      Ah, so, by extension you should be bitching about every shell that assumes I entered a command? Shouldn't I have to TELL IT to 'execute ls'? Why does it ASSUME that if I type ls I want to see a directory listing? Stupid shell, I hate them when they do things for me!

      And, you know, if a shell is going to make an assumption at all, I'd prefer it assume it's an expression than a command because if someone aliases ls with rm -fR, better it just echo that back then execute it, right?!?
      • Re:doing it for? (Score:3, Insightful)

        by memfrob ( 157990 )

        Why does it ASSUME that if I type ls I want to see a directory listing?

        The GP isn't so much complaining about the assumption, but the arbitrariness of it. In most UNIX shells, everything you type at the prompt is a command. In MSH however, it appears that sometimes when you type something in, it might be a command, it might be a value, it might be a.... etc.

        msh> 5
        5

        Who's to say I don't have a command called '5'? What if it's not in the correct path? Or, for that matter, who's to say I don't hav

  • ehh? (Score:2, Troll)

    by miffo.swe ( 547642 )
    Is this the very same commandline that was so cumbersome in Linux? Is it suddenly an asset just because its in MS Windows?

    NIN Syndrome at its finest....
  • by Xthlc ( 20317 ) on Monday October 24, 2005 @08:31AM (#13863263)
    I kill me.

    Seriously though, the design of MSH is odd. Their hybrid of paradigms from functional programming and OOP is just weird and inconsistent. Having completely different syntaxes for invoking "Commands" and "Methods" is obviously a byproduct of trying to have both a traditional shell syntax and OOPy goodness, without thinking much about internal consistency.

    Typical Microsoft: very use-case focused, at the expense of helping their users build a consistent mental model of how their system works. I bet it's pretty hard to do anything in MSH that its designers didn't specifically anticipate.
    • by kuzb ( 724081 ) on Monday October 24, 2005 @11:15AM (#13864504)
      Don't you mean "It doesn't act like, SH, ZSH, Bash, etc... AND IT WAS MADE BY MICROSOFT, BUUUURN!"

      I really don't understand people like you. You whine, moan and complain because Microsoft's command prompt sucks, and when they fix it, you go out of your way to find new things to bitch about. What is very interesting, is that if they HAD copied Bash, or one of the other unix command lines, you would have immediatly jumped on them for that too.
  • So after years of telling us that the command line is dead, it's not dead anymore? I'm confused...

    However, I am looking forward to lots of Windows users becoming "l337" overnight because they now know a couple of commands for msh, in much the same way as all gentoo users are uber coders, as they've regularly sat and watched screenfulls of text scroll past.
  • by CDPatten ( 907182 ) on Monday October 24, 2005 @08:39AM (#13863316) Homepage
    Hypothetically: What if MS pulls it off and puts out the best OS that the Linux guys have ever seen. Let's say it's the Longhorn Server, WinFS, Monad, and everything MS has been touting works. Remember this is a hypothetical here so save the flaming/trolling for another thread.

    Will the Linux guys at that point stop bashing MS? Will you consider using the MS OS? Now I understand you don't trust them, but how will you respond if you can't say their product sucks? Will the comments be, "Ya they make the best OS, but they are evil?" Or will you continue to say that "Windows is just crap because they don't share the kernel source?"

    We are starting to see more and more people say that MS is doing a good job (like the parent thread here), and much to my surprise they are starting to open up their formats and products a little (not completely I know, but moving towards that direction). By all accounts it looks like for the next 18 months MS will be releasing some decent software, most of it strides ahead of the OSS available. Not to say that MS isn't catching up to SOME open source products... but that's fine, they should add the best features to their product, why wouldn't they?

    Just an honest hypothetical here, I'm not trolling or anything, I'm trying to understand your stance a little better. The standard cliché response of "MS is a monopoly and EVIL" is fine, but I was hoping for more thought provoking responses.
    • by 99BottlesOfBeerInMyF ( 813746 ) on Monday October 24, 2005 @10:07AM (#13863939)

      Hypothetically: What if MS pulls it off and puts out the best OS that the Linux guys have ever seen. Let's say it's the Longhorn Server, WinFS, Monad, and everything MS has been touting works... Will the Linux guys at that point stop bashing MS? Will you consider using the MS OS?

      You're attempting to formulate a "what if" scenario, but as often happens you've oversimplified things on such a scale that it is meaningless. Linux admins do consider using MS products now, and deploy them occasionally where appropriate. As for "what if MS put out a better OS" well, I guess that depends upon what you mean by a better OS. The case for Linux vs. MS is both technological and business. Suppose the next version of Windows is technologically on par with, or better than, Linux as a server. It will still suffer from not being free of cost, not being customizable by the end user, locking the user into a single supplier for a critical component of a system, and putting customers in the position of having to deal with a company renowned for putting it's customers out of business using unfair tactics. No smart businessman wants any of those things. Even so, in some cases it makes sense to put up with those problems, and that is what smart administrators do.

      For example, If I run a smaller business and need specialty software only available commercially on Windows and I don't have the resources and contacts necessary to build a open solution on an open platform, then it makes a whole lot of business sense to buy a Windows machine, at least for that one component. If, on the other hand, I'm working for IBM or a company with similar resources, there is rarely any compelling reason to go with MS for anything, since the resources are available to get a better long-term ROI and TOC by using open source solutions. Why lock oneself into paying a competitor every year, with no competitive bidding, when for a slightly higher initial investment a free alternative, with free development, and some free support can be created, that also places IBM in the position of being a market leader in that particular niche and ties into the bread and butter services business.

      A good analogy might be, you invent a new desert pastry and it needs a fruit filling. You can use oranges, which you can get from any number of vendors, or grow yourself or you can use MSFruit which is patented and you can only buy from one supplier. Even supposing MS gains the edge in harvesting and processing technologies, does it make sense to sign a contract to use them as your sole supplier and agree to never alter your recipe or does it make sense to invest in better harvesting and processing technologies and keep using oranges so that you can take competitive bids and experiment with new recipes?

      Of course, as you said, this is all theoretical. MS is so far behind other solutions in so many areas that they have not even tried to address that it is unlikely MS will catch up any time soon. The fact that they keep introducing anti-features designed to benefit MS as a company and cost customers extra money somewhat counters other advances they make. They pay a lot of attention to bullet points and making things "good enough" while not really achieving that for a good portion of users. They have a few nice features that I'd say are better and more usable than anyone else, but at the same time they are really really behind in other areas and falling further behind all the time. Don't call me when they have pipes and scripting that work without writing any code and from the GUI. Don't call me when they allow programs to offer services to other programs. Don't call me when they fix the disaster they call managing programs. Don't call me when they no longer expose network services by default. Don't call me when they move to open APIs. Don't call me when they open and document their formats and support other open formats. Don't call me when they have workable non-admin accounts. Don't call me when they make the UI responsive during heavy multit

  • and don't worry about becoming dependent only to have a "Licen$e" fee imposed, or EULA restrictions about using GPL software in conjuction with it.

    Since VISTA is turning out to be just a theme upgrade, why not upgrade to Linux and stop shelling out more and more money just to get a new theme or security holes patched, or the stability improved?

    Duh!
  • it would finally be ready for the desktop.
    when will the linux devs get on the ball its 2005 the new wave of computing is the command line.
    who says microsoft doesnt inovate.
  • by bbzzdd ( 769894 ) on Monday October 24, 2005 @08:44AM (#13863349)

    Thank you Microsoft for updating the "DOS" shell. Us command-line jocks really do appreciate it. They were even nice to us switch-hitters in that "cd /windows/system32" (note the forward slashes) actually works now. I guess they concede they lost the slash wars after all these years :)

    But seriously. After spending in any time in a Linux or OS X sexy, semi-transparent shell windows, with a nice courier font and syntax highlighting, Monand (as it is now) still runs in the gross 1982 DOS window?

    I hope this changes come Long^M^M^M^M Vista

    • Is it Unicode yet?

      One of the great annoyances of cmd.exe is that it's ANSI only. Type 'dir' on a directory with different language filenames in it and you get a sea of questionmarks, and you have to use ugly 'chcp' commands to see different filenames... and forget about entering them at the keyboard.

      The console is Unicode.. it's deliberately downgrading itself just to be annoying. Makes multilingual stuff on NT really hard.

  • by Beautyon ( 214567 ) on Monday October 24, 2005 @08:50AM (#13863393) Homepage
    It looks just like eval.rb the interactive ruby shell:

    http://www.rubyist.net/~slagell/ruby/strings.html [rubyist.net]
  • hummm.... (Score:5, Insightful)

    by Vo0k ( 760020 ) on Monday October 24, 2005 @08:57AM (#13863436) Journal
    I'm on page 6 already and I must say I start liking msh more and more.
    It's completely un-microsoftish!
    - It's very easy to shoot yourself in the foot. Extremely easy - anything that is not a command is an expression that is evaluated, so a typo may pass unnoticed and without a warning.
    - It provides lots of sweet syntactic sugar making things easy and terse while not overly obscuring them.
    - It takes some of the best from lots of other languages. Shamelessly too. ($_, select, | etc)
    - It makes some evilly hack-friendly assumptions ("current instance" is the current directory)
    - It will likely suck as an interactive shell, but makes simple scripts to automate system tasks obscenely easy. Likely, no more repeating 1000 times "click add user, type username, type password twice, mark 'Password never expires', enter Groups, select 'staff', click 'add group', click OK, click OK".

    It really looks like the project was created by the programmers while the management was on vacations, then all the details hidden and managers just fed with marketspeech while programmers worked on a tool that would finally make THEIR OWN life easier, instead of just appealing to managers of customer companies and making programmers' life more painful.
  • Wow, interesting! (Score:2, Interesting)

    by ratta ( 760424 )
    I was thinking that microsoft would never provide such a thing, but only the unusable DOS/cmd.exe prompt, to make windows users think that "operating systems based on the command line are very difficult to use" :) I'm now interested to see how it maps with gnu bash, if it tries to superseed it with features or will be vaguely compatible with it... Nice!
  • direct download (Score:3, Informative)

    by rednuhter ( 516649 ) on Monday October 24, 2005 @10:45AM (#13864244) Homepage Journal
    This download offers you the benefits of registering with Microsoft. Click the Continue button near the top of this page to register.
    no thanks, I would rather just download it.
    http://download.microsoft.com/download/7/4/6/746ec 8ff-c4eb-41f3-884e-981bf39997b7/monad_b2_50215_x86 .zip [microsoft.com]
    taken from
    http://www.leeholmes.com/blog/CommentView,guid,8b2 6fea1-723d-4bd6-93c1-19d681af9276.aspx [leeholmes.com]
    (which also has the 64 bit version)
  • by tmortn ( 630092 ) on Tuesday October 25, 2005 @01:46PM (#13873836) Homepage
    Just in futzing with it for a bit I have some major beefs here. Yeah I know its just beta and that some if not all of this stuff is in flux but this is what I noticed.

    1) They still have the problem of cuting and pasting GUI environment info to the cmd shell window.

    2) They are still limited to crappy display levels for the cmd shell window

    3) If your building a verbose object oriented language you need a better refferencing system. Insane long wordy names are in theroy good and makes learning easier. But for repetative stuff it gets old typing them. Sure you can denote aliases... but why not always denote one by default? Just establish a best practices for creating a unique shorthand of the longer name.... and build it into the script to check with help to make sure its not walking on anything else. I garountee anyone that uses this thing for any length of time is going to create a shorthand for it... if there is one by default it will make it easier for people to talk it without first establishing what they all call their aliases for which function.

    4) More works but is not listed under help. It has a flaw in that when you advance a single line it continually types the instructions just under the new line without deleting the old line... ie if you advance by line you then have alternating document info and instruction lines rather than the document txt incremeting above the instruction line ie...

    (q)for quite (cr) for next line (space) for next page
    Line of text from the file
    (q)for quite (cr) for next line (space) for next page
    Line of text from the file
    (q)for quite (cr) for next line (space) for next page
    Line of text from the file

    Extremely annoying.

    Some other thoughts.

    Why are they trying to limit themselves to creaky old txt displaying methodologies ? Yes a command line consists of text information primarily but the reason it evolved in such a constricted interface was that there was no other option at first. Just because it is a command line does not mean it could not also be a gui. Give it the power of both. For instance lets say I open my computer. I get the standard drive icons etc and at the bottom I get a prompt. If I double click C or type cd c:\ at the prompt the same results happen on screen. Lets say I drag a file down to the command line.. now a token appears there for dealing with that file. I have a graphical rpresentation as well as text information and I can interact both with a mouse and with cmd line input.

    Additionally they spent a crap load of time developing a pretty slick interface in the Studio .NET IDE... why not adapt that for a cmd line interface ? ie pull down lists of functions with a properties windows and the ability to explore the help information and view examples ? All in a tabbed interface. Sweetness.

    The marriage of the command line and the GUI is the next generation. It does not have to be EITHER OR. Both have strengths and both have weaknesses. Instead of being stuck with one or the other create a system that allows you freedom to use both sets of strengths to offset the others weaknesses.

Stinginess with privileges is kindness in disguise. -- Guide to VAX/VMS Security, Sep. 1984

Working...