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

668 comments

  1. No Thanks by md81544 · · Score: 2, Insightful
    Does this remind anyone of the old quote:
    Those who do not understand Unix are condemned to reinvent it, poorly

    I'll stick with bash or ksh, thanks very much. But thanks for trying.
    1. Re: No Thanks by Transcendent · · Score: 2, Insightful

      I'll stick with bash or ksh, thanks very much. But thanks for trying.

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

      So to answer your question... no... it doesn't remind me of that quote, because it has no relevance to it.

    2. Re: No Thanks by Anonymous Coward · · Score: 0

      Ok, but does bash or ksh run on windows?

      Yes.

    3. 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. --
    4. Re: No Thanks by grumbel · · Score: 1

      ### Ok, but does bash or ksh run on windows?

      Sure they do, like almost all Unix software, either via the full blown Cygwin or via the more lightweight MSYS.

    5. Re: No Thanks by 0x461FAB0BD7D2 · · Score: 1

      Try Cygwin. And Monad doesn't run on all Windows platforms, unlike Cygwin. It would only work on LH and XP (if they decide to port it back).

      The OP is trying to say that they are reinventing Unix with LH, evidenced by the new virtual folders, file permissions, new scriptable shell and so on.

    6. Re: No Thanks by ryants · · Score: 1
      Ok, but does bash or ksh run on windows?
      Yes
      --

      Ryan T. Sammartino
      "Ancora imparo"

    7. Re: No Thanks by Phil+John · · Score: 1

      Yes they do actually, ever heard of the cygwin portability library/distribution.

      Because of that I have all manner of unix/linux/bsd utilities that have been recompiled for windows. I can diff, patch, make, ./configure, gcc, vi(m), emacs, bash, ksh, lynx, wget, scp, ssh and even use x.org to my hearts content. It's a good compromise when you have to stay on windows for one reason or another.

      --
      I am NaN
    8. Re: No Thanks by Anonymous Coward · · Score: 0
      It does remind me of the quote. And bash/ksh are available, granted it's through cygwin whose installer woes continue to bite my balls. I will be downloading Monad to test it out, as I love me my shells! Kinda interested to see how fucked up the XML pipeline action is.

      Oh and btw, zsh rules, bash drools!!!!!

    9. Re: No Thanks by Daniel+Dvorkin · · Score: 1

      Ok, but does bash or ksh run on windows?

      As a matter of fact ...

      --
      The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
    10. Re: No Thanks by PyWiz · · Score: 0, Informative

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

      Actually, yes, it does. Ever heard of cygwin? You can run a host of linux tools and shells on there including bash and ksh. I use it on my home computer so I don't have to continually reboot my computer just to use gcc or something of the like when I'm on Windows.

      --
      -py
    11. Re: No Thanks by dreamchaser · · Score: 1

      I guess you've never seen bash or ksh for Windows then.

    12. Re: No Thanks by FrankNputer · · Score: 1

      Ok, but does bash or ksh run on windows? Actually, they do. Now go outside & play.

    13. Re: No Thanks by Anonymous Coward · · Score: 0

      Only on Slashdot could such a pathetically stuck-in-the-70's post get modded up 'insightful'. I bet your the same kind of person that would say 'Spotlight? I'll stick with grep, but thanks for trying'.

    14. Re: No Thanks by Anonymous Coward · · Score: 2, 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...

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

    16. Re: No Thanks by SourKAT · · Score: 2, Funny

      With the number of replies you got, don't you feel just a little bit stooooopid? You do know that Life's like a box of Chocolates, don'tcha?

    17. 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!
    18. Re: No Thanks by Anonymous Coward · · Score: 0

      I'll stick with bash or ksh, thanks very much.

      Yeah... Nice unique golden scepter there, too bad you're holding up two of them.

    19. Re: No Thanks by Nimrangul · · Score: 3, Interesting

      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.
    20. Re: No Thanks by md81544 · · Score: 1

      I don't think perfection will ever exist; I'm simply quoting from my experience. I'm a programmer who uses both UNIX (AIX/Solaris AND Linux) as well as Windows. And the only way to write decent scripts on Windows is via Cygwin (see many responders to my original post).

      I'd welcome something brilliant in MSH but somehow (given their lack of creativity) I'm not holding my breath. Love and Peace and all that - I'm not interested in flame wars.

    21. Re: No Thanks by Dave2+Wickham · · Score: 1

      Yes; to add to what others have said, Microsoft even distribute (pd)ksh as part of Services for Unix; see "Robust Scripting Environment" on this page.

    22. Re: No Thanks by Southpaw018 · · Score: 1

      Um...parent should be modded troll, not insightful. What, Microsoft isn't allowed to develop their own shell based on what those who will use it (mostly /. types) think a shell should be?

      --
      ACs are modded -6. I don't read you, I don't mod you, I don't see you. Don't like it? Don't be a coward.
    23. Re: No Thanks by bersl2 · · Score: 2, Insightful

      He's not talking about Unix per se when he says "Unix"; you should instead read it as "the Unix Way," which will not likely end up deprecated for a long time.

    24. Re: No Thanks by Dave2+Wickham · · Score: 1

      Damn, beat me by a minute.

    25. Re: No Thanks by Anonymous Coward · · Score: 0

      In fact the idea is great and linux besides the kernel is much a bloatware just because it is so much command-line dependent. If i could (lack of money not lack of skillz), i would extend this idea not just by use objects but by assembling together algorithms with default configuration and functional scripting (ie if you use X trigger you can't use Y one) as single functions available in linux just like library functions from c like cmdline. This would allow to build eg. iptables command which could be executed in cmd-line (stdout = text) just like original one with even same wrapped arg names, text-gui like alsamixer and x-gui. And OS would interprete scripting on-fly (and i mean binary compiled ones, not like xml human-readable but GHz-killing ones), leaving programming GUI/parsing cmdline unnecessary for programmer. This would be goodbye for bloat (maybe up to 10% of all cmdline tools is analyzing of it's arguments and dc-gui like crappy tools appear just because it's easier to do it this way). But in a perfect world...

    26. Re: No Thanks by bersl2 · · Score: 0, Flamebait

      kill -9 that one. Parent post doesn't make sense.

    27. Re: No Thanks by Anonymous Coward · · Score: 0

      what

    28. Re: No Thanks by TheAncientHacker · · Score: 1

      Ah, yes. The classic conceit of those with tunnel vision: Anyone doing anything different is only making a bad attempt to do what I already know...

      Grow up sheeple, the world really didn't begin and end with Unix.

    29. Re: No Thanks by Anonymous Coward · · Score: 0

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

      And those who refuse to evolve beyond Unix are condemned to live in the past. But that's OK, the past can be a comfortable place. Enjoy your stay. Meanwhile, some of us are moving on.

    30. Re: No Thanks by joeykiller · · Score: 1
      I'll stick with bash or ksh, thanks very much. But thanks for trying.
      If that sums up your technology view in general, why do you use computers? It can't be because you enjoy innovation.

      To me, Monad is an exciting effort to try to reinvent the command line. The simplest aspect of Monad to grasp is that it's a CLI with something similar to GUI guidelines: If you know command switches for one program, you should be able to guess/know the switches for other commands/utilities/programs.

      But's what's more interesting is how it moves the pipe paradigm over to the object oriented world of .Net. Programs can pass objects to each other and manipulate their contents. This gives you extreme programmability, along with control over programs, processes, etc.

      If you're a Windows user, you should really look into it: I'm a bash fan myself (I use Cygwin on Windows for my shell needs), but in my opinion this is actually the first exciting development in command lines in a long, long time. Of course I have to relearn a lot of what I know already, but if that gives me even more control and flexibility it's a small sacrifice to make (maybe I'm this positive because my systems aren't depending on thousands or millions of lines of custom made shell code).
    31. Re: No Thanks by Anonymous Coward · · Score: 0

      Hahahaha.

      A bit harsh, but funny.

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

    34. Re: No Thanks by shm · · Score: 1

      Thanks, but no thanks. I'm stuck with using Windows thanks to pointy haired decisions - the enjoyment of running cygwin and figuratively thumbing my nose at the PHBs would be significantly reduced if I used SFU. (Now why do I read that as STFU?!?)

    35. Re: No Thanks by brpr · · Score: 2

      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.

      What do you mean by "command line compliant"? Most Linux GUI software isn't usable from the command line, so how is Linux any different in this regard? If anything, because of its .NET object base, Mono should be easier to integrate with GUI apps than bash.

      --
      Freedom is not increased by mere diminuation of government. Anarchy is freedom for the strong and slavery for the weak.
    36. Re: No Thanks by pete6677 · · Score: 1

      The biggest hurdle for Monad will be peoples' inability to say the name with a straight face. Seriously, who the hell came up with that name? I can only imagine what it would be like to try to tell my boss about this exciting new technology from Microsoft called Monad.

    37. Re: No Thanks by bersl2 · · Score: 1

      Many Linux GUI programs are just frontends. There is very little I can't do from the command line and/or by editing a text file.

    38. Re: No Thanks by Anonymous Coward · · Score: 1, Funny

      you're such a rebel.

    39. Re: No Thanks by The+Only+Druid · · Score: 1

      How old are you? I cant figure out if you're making a bad joke ("oooh, NAD!") or a troll who thinks this is an actual criticism of the software.

      --
      "Stumble before you crawl"
    40. Re: No Thanks by VistaBoy · · Score: 1

      Just pronounce it mon-ed instead of mon-add. That way, it doesn't sound like gonad.

    41. Re: No Thanks by B'Trey · · Score: 2, Insightful

      Yes, that's how *nix does things. Small, sharp tools. Wonderful paradigm, and if you want to say that it's a better way to do things, well, someone may argue with you about it but I certainly won't. But, for better or worse, it's not how Windows does things. Monad looks to have lots of hooks into the Windows kernel and various low level functions that simply aren't available as an independent utility. It's still early, so it's difficult to say how things are going to turn out, but it seems likely that Monad will have capabilities and feathers that Cygwin/bash won't have. That'll be a huge boon to those of us who have no choice but to deal with Windows in our profession.

      --

      "The legitimate powers of government extend only to such acts as are injurious to others." Thomas Jefferson.

    42. Re: No Thanks by Anonymous Coward · · Score: 0

      As a former MS employee, I'll say there are quite a few ways to run standard shells. Of all the internal goodies, there are a few set of ported *nix tools.

    43. Re: No Thanks by SubTexel · · Score: 1

      Ummm yeah... like KSH is sooo much of a better name.. or BASH, Gimp, Gnome, etc.. Grow up.

    44. Re: No Thanks by James_Aguilar · · Score: 1

      Many windows gui programs can be started from a command line and using command line switches. Many can operate on input from the standard input as well.

    45. Re: No Thanks by NutscrapeSucks · · Score: 1

      No, it proves the quote wrong. Windows is not a reinvention of Unix, which is exactly why a Unix-style shell isn't very useful.

      --
      Whenever I hear the word 'Innovation', I reach for my pistol.
    46. Re: No Thanks by Waffle+Iron · · Score: 1
      But's what's more interesting is how it moves the pipe paradigm over to the object oriented world of .Net.

      I'm skeptical that it's going to work very well. I still remember when DCOM was going to seamlessly combine object-oriented programming with networked messaging. It ended up pretty much being a nightmare to use, and has been largely deprecated in favor of RPC schemes that better match the characteristics of actual networks.

      Maybe they'll get this to work as smoothly as the more limited stream-based shells like bash, but I wouldn't be surprised if it takes them a decade and a few redesigns before they get it right.

    47. Re: No Thanks by glenebob · · Score: 1

      Because all we really want is a Unix shell on Windows. If they would have made that a working reality from the get go, everybody would have been happy.

      Why would we get excited over a newly invented wheel from a bunch of clowns who have never understood the importance of the wheel? We want THE wheel, the one that we know works, the one we already know how to operate, the one that will leverage decades of infastructure and experience.

      I don't think you have to be a zealot to simply want what already works.

    48. 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!
    49. Re: No Thanks by callipygian-showsyst · · Score: 2, Interesting

      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.

    50. Re: No Thanks by ReallyNiceGuy · · Score: 1

      Never mind... ;)

    51. Re: No Thanks by thinkninja · · Score: 1
      I'll stick with bash or ksh, thanks very much. But thanks for trying.

      Give ZSH a try. It's got all kinds of neat-o features like advanced prompting and filename generation -- never use find again!
      --
      "The number of Unix installations has grown to ten, with more expected." (Unix Programmer's Manual, 2nd ed.; june 1972)
    52. Re: No Thanks by Anonymous Coward · · Score: 0

      Not to be an ass, but the unix way would be to put those other functions into seperate utilities where they belong. And then make those utilities integrate well with the shell, pipes, etc.

    53. Re: No Thanks by nvrrobx · · Score: 1

      I have to disagree with you - as a developer who uses Windows as his primary OS at work, I live on the command line.

      I may not write apps that are friendly to the command line, but this will certainly help improve build scripts, automated processing, and my general development.

      It is a little verbose, but that will make it more user friendly. Let's face it, bash and the UNIX commands are amazingly powerful, but they're NOT intuitive.

    54. Re: No Thanks by brpr · · Score: 2

      Many Linux GUI programs are just frontends. There is very little I can't do from the command line and/or by editing a text file.

      OK, fair point. But on the other hand, the ability to use all the libraries in the .NET framework will give a pretty decent equivalent to the library of command line tools on Linux. Say, fetching a webpage would still be easy.

      --
      Freedom is not increased by mere diminuation of government. Anarchy is freedom for the strong and slavery for the weak.
    55. Re: No Thanks by Zimzat · · Score: 1

      intuitive:
      command --help
      man command

    56. Re: No Thanks by Anonymous Coward · · Score: 0

      When I hear you talking about fetching a web page, then I'm thinking about perl and not about bash. Perl has everything that bash misses. And bash misses a lot...

    57. Re: No Thanks by man_of_mr_e · · Score: 1

      What I don't understand is why you even NEED a shell to execute scripts. It seems to me that this is the most un-unixy thing about unix. That is, the philosophy of discrete components that do one thing well.

      When you can simply execute any scripting language through the #! syntax, what point is there in having a monstrous shell that executes scripts?

      Other than extremely simple scripts that don't warrant the overhead of loading perl or python or whatever, it just makes no sense to me.

    58. Re: No Thanks by Burz · · Score: 1

      So Monad is the MS answer to bash + /proc ?

    59. Re: No Thanks by Osty · · Score: 1, Informative

      Monad looks to have lots of hooks into the Windows kernel and various low level functions that simply aren't available as an independent utility.

      What? MSH has absolutely nothing to do with the Windows kernel. Perhaps you've mistaken its "native" access to things like the registry as "hooks into the Windows kernel". That functionality is not "built-in", but available through a default set of "providers". You can write your own provider to add new functionality. Similarly, most of the functionality of the shell itself is not built-in, but provided by a bunch of default cmdlets (small bits of code either provided in a .NET assembly or even written as a MSH script that perform some task). Where in unix you'd write an application like grep or a small script to process some data, in MSH you'd write a cmdlet. Like unix providing you many useful bits by default like grep, awk, cut, or sed, MSH provides a bunch of useful cmdlets by default like select-object, where-object, or sort-object.

      Off-topic about names: Monad/MSH follows a "verb-noun" standard. Thus what would be "sort" in unix is "sort-object" in MSH (beause it "sorts" a bunch of "objects"). As many others have pointed out, you can use aliases to make these names shorter (MSH ships with a bunch of default aliases to provide both dos-like and unix-like functionality).

    60. Re: No Thanks by man_of_mr_e · · Score: 1

      Unfortunately, your premise is in fact wrong. This is why Monad won't be released for another 3 - 5 years. They ARE in fact rewriting everything to work under Monad.

    61. Re: No Thanks by Fittysix · · Score: 1

      They could always build the command line around the UI, every UI widget in a program has a unique identifier, if you could command-line script the UI you could basically script any given program built on dotnet. Even if the scripting is as tedious as:
      Checkbox(id).checked = true
      textbox(id).text = "text text"
      Button(id).click
      which, you'll notice looks a lot like c#/vb.net

      --
      *.sig
    62. Re: No Thanks by Ambassador+Kosh · · Score: 1

      With kde you can script just about everything from the commandline using dcop. There is a program you can use called dcop from the commandline so you can use pipes etc but there are also language bindings for c,c++,java,python, perl, ruby and others. Now if kde and gnome could just get a shared object system that would solve the issue also. Work is progressing on that also.

      --
      Computer modeling for biotech drug manufacturing is HARD! :)
    63. Re: No Thanks by Anonymous Coward · · Score: 0

      Fortunately, there's already a GNU version of this, called Gonad.

    64. Re: No Thanks by eugene_roux · · Score: 1
      He's not talking about Unix per se when he says "Unix"; you should instead read it as "the Unix Way," which will not likely end up deprecated for a long time.

      Don't even bother trying to explain it to him...

      He is just another WinTroll, and like all WinTrolls he is more intent in muddying the waters and hopefully keep someone else from switching to Free/Open Source Software than actually understanding the realities behind the Unix philosophy.

      WinTrolls sort of brings to mind Creationists (or whatever they get called this week) refusing to understand and/or acknowledge fundamental realities.

      It is easier to call into doubt the definition than argue the point, you see. It is easier to use inflammatory language (calling them "bigots") than acknowledging the possibility of having to re-educate yourself.

      Thank heavens Unix users learn to think (understand) first, which leads to a thankfully lower resistance to change.

      --
      Part Time Philosopher, Oft Times Romantic, Full Time Unix Geek
    65. Re: No Thanks by Bloater · · Score: 1

      They have this already, it's called python. really makes a great shell in windows. Gets rid of all that nasty racy - choose a file, run a program with its filename, meanwhile the file has been moved underneath you. Interacts with COM too (needs some tab completion though). I am gonna look into using ruby for this stuff too. I think you may be able to add definitions to classes/objects after the fact (not sure though), which would be ideal for an interactive scripting shell.

      Monad - Python for Microsoft zealots.

    66. Re: No Thanks by Anonymous+Brave+Guy · · Score: 1
      The vast majority of software running on a Windows platform was not written with command line operability or scripting in mind.

      However, an awful lot of the stuff you'd want to automate provides interfaces via COM and more recently .Net. With a shell that can understand these concepts, it really doesn't matter if you can't control everything with a single string of characters at a command line, because that's a child's toy in comparison anyway. That is why Monad has so much potential, and why it's not just another immitation *nix shell.

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    67. Re: No Thanks by moonbender · · Score: 1

      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.

      That's the cool thing though. First of all a vast amount of software running on a Windows platform is written by Microsoft themselves. But aside from that I think the major advantage platforms with one dominant actor such as Windows or OS X have over an open platform like Linux or the BSDs is that standards set by the central authority typically are adapted by everyone else. This means that Apple can introduce a basic search system and rely on third parties to extend it and it means that MS could introduce something like MSH and rely on others to write compatible applications. It's easier to reach "critical mass" if one party produces so much functionality.

      --
      Switch back to Slashdot's D1 system.
    68. Re: No Thanks by TheGavster · · Score: 1

      Even if you can't get over rhyming it with things, the fact that there is 'from Microsoft' in there means instant acceptance from management.

      --
      "Because Science" is one step from "Because old book". Try "Because of my experiment testing my falsifiable assertion".
    69. Re: No Thanks by Bishop · · Score: 1

      Much of the Windows core functions are acessible from the command line. Microsoft has been loath to document any of it, and it is not pretty. But much of it is there. I have seen more then a few voodoo command lines from Microsoft that bypass the gui. The really sick stuff uses rundll.

      This dosen't help if you are trying to script a 3rd party app, but *nix and MacOS are in a similar boat. All three systems have features to expose functions, but those features aren't always used.

    70. Re: No Thanks by Anonymous Coward · · Score: 0

      however, most, if not all of these are acronyms. So instead of saying something like "Hey boss, we'll be using the gimp", you'll announce the switch to the gnu image manipulation program. big names always win.

    71. Re: No Thanks by marcosdumay · · Score: 1

      Have you never noted the similarity with "those who don't understand history are doomed to repeat it"? UNIX people dismiss every revolutionary attempty to modify what they know because history has already showed that they are quite right about the way they do stuff (they wheren't always right, but fixed several things already).

      If someone starts to create something completely new, he will make much of the mistakes that we already made after UNIX and on the earlier systems, so will come with something almost useless. If he, however, start from UNIX and improves it bit by bit, he'll probably get a better system.

    72. Re: No Thanks by X0563511 · · Score: 2, Interesting

      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...
    73. Re: No Thanks by Prothonotar · · Score: 1

      In most cases, shell scripting (such as with bash) is more high-level than Perl scripting, and therefore tend to be simpler than the equivalent Perl script (not counting esoteric unreadible perl scripts). The drawback is that the shell is not as robust- there are some things that you just need to do in Perl, and as the tasks get more complex, you end up having to jump through more hoops with bash than with a full-fledged language.

      --
      "Every man is a mob, a chain gang of idiots." - Jonathan Nolan, Memento Mori
    74. Re: No Thanks by Beale · · Score: 1

      Said Captain Open-minded.

    75. Re: No Thanks by julesh · · Score: 1, Flamebait

      and Microsoft has their own product, free download,

      Oh, SFU noob.

    76. Re: No Thanks by B'Trey · · Score: 1

      Not to be an ass, but isn't that pretty much what I said?

      --

      "The legitimate powers of government extend only to such acts as are injurious to others." Thomas Jefferson.

    77. Re: No Thanks by julesh · · Score: 2, Interesting

      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.

    78. Re: No Thanks by Anonymous Coward · · Score: 0

      Not true. It'll run on any OS that supports the new .Net framework 2.0. I've successfully installed the .Net framework beta on 2000 and 98SE without issue.

    79. Re: No Thanks by julesh · · Score: 2, Informative

      Why is everyone immediately saying cygwin? Windows Services for Unix is the official release of ksh for Windows.

      'cause 95% of us think that ksh is a horrible, horrible shell, and that bash "rulez".

    80. Re: No Thanks by nvrrobx · · Score: 1

      If you're a newbie, there's nothing intuitive about:

      grep
      awk
      sed
      ln
      mv
      ls

      Shall I continue? I get to field questions from coworkers about what UNIX command does what all the time.

    81. Re: No Thanks by Sancho · · Score: 1

      I think when he said "Windows developers" he meant people who develop on/for Windows, not people who develop Windows.

    82. Re: No Thanks by Anonymous Coward · · Score: 0

      It's as dangerous as writing any other app that runs on any OS.

      It's not in any special 'danger' group because it's a scripting language.

      Remember, you can screw up your computer just fine with a batch file, QBASIC program or C++ app, to name a few.

      (Assuming you're running as admin, which you shouldn't be anyway)

    83. Re: No Thanks by rekoil · · Score: 1

      Well, I'm sure it has no more hooks into the Windows kernel than "bash:# cat foo > /proc/bar" has into a UNIX kernel...

    84. Re: No Thanks by Anonymous Coward · · Score: 0
      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)?

      The reason I think, is simple. These are also the same people who aren't really that adept at anything other than computers. Make the user experience easier and you take away from their exulted sense of superiority. These are the same people who liken an OS to the next great crusade to rid the world of evil. Quite simply, they're utterly delusional.

    85. Re: No Thanks by Cobralisk · · Score: 1

      How can a reply to yourself(a retraction at that) be flamebait?

      --
      Waiting for ad.doubleclick.net...
    86. Re: No Thanks by Cobralisk · · Score: 1

      I like this analogy. You ask MS for a wheel, so they give you a hexagon, with gear teeth, made of lead, gold plated, and (somehow) flammable. Can you use it? Yes, but is it useful? Why can't you just have a wheel? Why does it only accept metric sized axels? Why does it have your social security number etched on it? Must it really leave holes in the road? And you think you get how it works, but what are the 3 seashells for?

      --
      Waiting for ad.doubleclick.net...
    87. Re: No Thanks by f0d0 · · Score: 1

      That's exactly why!

    88. Re: No Thanks by ucblockhead · · Score: 2, Informative

      Probably because cygwin takes ten minutes to install and is a snap to use while SFU is a royal pain in the ass to install and maintain.

      --
      The cake is a pie
    89. Re: No Thanks by Anonymous Coward · · Score: 0

      Not only that, but MSYS/MinGW... That's a better solution than Cygwin IMHO. Because MSYS/MinGW doesn't try to emulate Unix, it presents bash etc. as native Windows programs, no CYGWIN.DLL or whatever.

    90. Re: No Thanks by pete6677 · · Score: 1

      This is very sad but true. I know of companies that use all things Microsoft just because management feels "safe" with them, even stuff that is totally useless (like Microsoft MOM, whatever that stands for).

    91. Re: No Thanks by pulitz · · Score: 1

      You're obviously ignoring Microsoft's power to control its army of developers. Does this ring a bell at all? DEVELOPERS, DEVELOPERS, DEVELOPERS, DEVELOPERS Microsoft dictates the rules, its developers follow closely behind.

    92. Re: No Thanks by AddressException · · Score: 1
      You can write your own provider to add new functionality. Similarly, most of the functionality of the shell itself is not built-in, but provided by a bunch of default cmdlets (small bits of code either provided in a .NET assembly or even written as a MSH script that perform some task).

      Wow, that sounds much easier than the UNIX way....
      As many have already said: Those who do not understand Unix are condemned to reinvent it, poorly
    93. Re: No Thanks by mverwijs · · Score: 1

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

      It does natively (no cygwin) with Unxtools for Windows! Eventhough sh.exe is zsh, not bash of ksh.

      It's the first thing I install on a Windows machine.

    94. Re: No Thanks by Mr.+Underbridge · · Score: 1
      Have you never noted the similarity with "those who don't understand history are doomed to repeat it"? UNIX people dismiss every revolutionary attempty to modify what they know because history has already showed that they are quite right about the way they do stuff

      What are these revolutions? Windows? Certainly not Macs, lots of unix people own those.

      (they wheren't always right, but fixed several things already)

      Doesn't that negate your previous point?

    95. Re: No Thanks by itchy92 · · Score: 1

      You can do this with VBScript. I used it to automate a *very* poorly-designed imaging procedure, which had us doing two hours of identical setup on every machine, then transferring over the user's profile (which should have been stored on the network to begin with).

      Anyway, for a few tasks where I couldn't interact directly with the shell, I had VBScript parse the active window and enumerate the controls on it, which allowed me to manipulate them as you suggested.

      --
      Slashdot: News for nerds. Stuff tha-- MICRO$OFT IS THE DEVIL!!1
    96. Re: No Thanks by mark(florida) · · Score: 1

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

      Please .......... you can't be serious.

    97. Re: No Thanks by stam66 · · Score: 1
      I'm sorry, but what the name really is stupid.

      monad : noun technical
      - a single unit; the number one.
      - Philosophy (in the philosophy of Leibniz) an indivisible and hence ultimately simple entity, such as an atom or a person.
      - dated Biology a single-celled organism, esp. a flagellate protozoan, or a single cell.

      At least 2 of 3 definitions are stupid, and come on, they must've thought people would be calling it gonad, no matter what their age...

      If you thought Monad was a good name for a CLI, then watch out for Penus, my replacement for it's man system!

    98. Re: No Thanks by Osty · · Score: 2, Interesting

      Wow, that sounds much easier than the UNIX way....

      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.

      As many have already said: Those who do not understand Unix are condemned to reinvent it, poorly

      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.

    99. Re: No Thanks by sydb · · Score: 1

      That's odd, I could swear you're saying to do x instead of doing x. I would say, "rhyme it with gone-add, don't say moan-add".

      --
      Yours Sincerely, Michael.
    100. Re: No Thanks by stor · · Score: 2, Funny

      +5 for this tripe?

      SFU is a joke. What kind of circus you running there?

      Cheers
      Stor

      --
      "Yeah well there's a lot of stuff that should be, but isn't"
    101. Re: No Thanks by Anonymous Coward · · Score: 0

      An outstanding difference is that under Linux (nearly?) everything is treated as a file and because of this bash's role (or insert your preferred shell here) becomes much more then what an "interface to the file system" implies.

    102. Re: No Thanks by SETIGuy · · Score: 1
      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.

      Bzzztt! (for the registry at least). Cygwin presents the registry as it should be....

      alien:/> uname -a
      CYGWIN_NT-5.1 alien 1.5.17(0.129/4/2) 2005-05-25 19:38 i686 unknown unknown Cygwin
      alien:/> cd /proc/registry
      alien:/proc/registry> ls
      total 0
      0 ./
      0 ../
      0 HKEY_CURRENT_CONFIG/
      0 HKEY_LOCAL_MACHINE/
      0 HKEY_CURRENT_USER/
      0 HKEY_PERFORMANCE_DATA/
      0 HKEY_CLASSES_ROOT/
      0 HKEY_DYN_DATA/
      0 HKEY_USERS
      alien:/proc/registry>
    103. Re: No Thanks by Anonymous Coward · · Score: 0

      HAhahahah HAhahahaha hahahahhaha

      That's a good one.

    104. Re: No Thanks by Runagate+Rampant · · Score: 1

      why you even NEED a shell to execute scripts

      portability

    105. Re: No Thanks by merky1 · · Score: 1

      Yeap, it will be a great boon, just like VBscript helped admins so much. Most admins will be unable to utilize the new functionality, making the primary use of the new shell viruses and exploits.

      Thank god I am no longer the "Windows" guy at work.

      --
      --WooooHoooo--
    106. Re: No Thanks by zonker · · Score: 0

      how about mortice kern systems toolkit? these guys have been around forever doing unix on windows.

      an uncle of mine used to swear by mks toolkit and another program who's name i can't remember but i remember the box cover was a picture of a shell and the name was something like concentric... can anyone toss me a bone and recall who that was?

    107. Re: No Thanks by Anonymous Coward · · Score: 0

      reg.exe helps for a few things.

    108. Re: No Thanks by Anonymous Coward · · Score: 0

      Have you ever tried SFU? You can go waddling around saying "Linux Roolz" and "I want to have sex with steve jobs" but if you've never tried the Microsoft product, you can't comment on it.

    109. Re: No Thanks by leonard_chung · · Score: 2, Informative
      The thing here is that with Monad is that folks aren't required to write specifically for Monad.

      Since Monad can instantiate objects and call methods on any .NET Framework class that's public, any windows developer who writes anything using the .NET Framework will automatically have their classes accessible to Monad.

      This is the case with many developers who are writing for any sort of managability. If they want an even nicer syntax, then they can custom write cmdlets which would then use a full verb-noun semantic for an even nicer user experience, but it's not required.

      Finally, it's really easy to write Monad cmdlets if you already have the .NET class implemented. The most basic version of get-process is a grand total of 5 lines of code. Leonard

    110. Re: No Thanks by cp.tar · · Score: 1
      If you thought Monad was a good name for a CLI, then watch out for Penus, my replacement for it's man system!
      Can't... resist... must... type... like... this...

      And it's all from Micro soft.

      Yeah, I know it's lame.

      --
      Ignore this signature. By order.
    111. Re: No Thanks by SeaFox · · Score: 1

      I have mod points but there doesn't seem to be a "foolish" option.

    112. Re: No Thanks by Anonymous Coward · · Score: 0
      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.

      Actually what you are (no doubt facetiously) running is "Unix SFW" - It's UNIX services for WINDOWS. Obviously bgInc. would never be caught dead (unfortunately - that would be quite an improvement in the state of affairs for them to be caught exactly that) actually producing a "Windows SFU" - windows services for unix Oses.

      Truthfully, calling this 'product' name "windows SFU" for this product reaches new heights in arrogance and cynicism, even given the record-shattering arrogance and cynicism of billy bathgates.

    113. Re: No Thanks by Anonymous Coward · · Score: 0

      Actually a decent amount of it was, via COM, which is a much more object oriented model that the stream manipulation you have to deal with in UNIX. Like CORBA, except not ubershit. It's fairly pervasive throughout Windows applications.

    114. Re: No Thanks by callipygian-showsyst · · Score: 1
      Nope! It's called SFU

      Seriously, why don't you take your head out of the sand and at least look at the products Microsoft offers. Then you can make an informed decision. Otherwise, you just sound like a silly zealot.

    115. Re: No Thanks by Ucklak · · Score: 1

      Monad will be the layer that a whole new batch of viruses will be written on top of.

      --
      if you steal from one source, that is plagiarism, if you steal from many, well, that's just research.
    116. Re: No Thanks by Runagate+Rampant · · Score: 1

      I have to agree that the Windows for command has got to be the most "intuitive" command I've ever seen! Yeah anyone new to Windows who wanted to set a variable to the output of a command would immediately just think:

      for /F "usebackq delims==" %i IN (`some command`) DO @set var=%i
      rather than the esoteric bash alternative:
      var=`some command`
    117. Re: No Thanks by callipygian-showsyst · · Score: 1
      Here's an unbiased source (by definition a neutral point of view!) that says about SFU:

      Unlike Cygwin, Interix is not implemented above the Win32 subsystem, but rather as an environment subsystem directly on the Windows kernel. This significantly improves performances and increases stability and security compared with the emulation used by Cygwin.

      In other words, this is the Posix API implemented on top of a microkernel. Sounds a lot like your beloved Mac OS-X to me. Of course, that was one of the guiding priciples behind Windows NT--a microkernel platform upon which several different standard OS APIs could be implemented.

      You need to start looking at everything out there, and stopped being brainwashed by the Linux/MacOS zealots!

    118. Re: No Thanks by Durf · · Score: 1

      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.

      Yeah, sure, that sounds likely. Next I suppose you'll spin some tale about Apple going to Intel processors.

    119. Re: No Thanks by eraserewind · · Score: 1

      > ls /proc/registry
      HKEY_CLASSES_ROOT/
      HKEY_CURRENT_C ONFIG/
      HKEY_CURRENT_USER/
      HKEY_DYN_DATA/
      HKEY_L OCAL_MACHINE/
      HKEY_PERFORMANCE_DATA/
      HKEY_USERS/


      Reason: Don't use so many caps. It's like YELLING
      Reason: Don't use so many caps. It's like YELLING
      Reason: Don't use so many caps. It's like YELLING

    120. Re: No Thanks by LnxAddct · · Score: 1

      Look at this from MSH's sample scripts page:

      Remove leading and trailing white space and all blank lines in MSH:
      filter Trim-SparseText{$_ = $_.Trim();if($_){$_;} }

      Remove leading and trailing white space and all blank lines in BASH:
      sed 's/^[ ]*//;s/[ ]*$//' | sed '/^$/d'

      Now both seem pretty confusing to a typical user right? Difference is, one uses industry standard regex's and the other uses a new syntax based off of .net. More importantly, MSH's version will only work with programs compatible with MSH where as the unix version will work with any program that shoots text out. In addition to that, there are no logical statements like "if", or the idea of functions or methods to learn. Unix scripting was designed for system administration, sysadmins shouldnt have to become .net coders just to effectively automate administration. Bash has administrators in mind, where as MSH seems to have been designed by coders for coders (any unix person that needed that situation would jsut use an interactive scripting shell like Ruby or Python). For someone starting to learn one or the other, the sed way is much better, plus you'll be learning regex's which are very useful in many more areas. Sometimes Microsoft should just take the hint and use something that has been refined for over 30 years now. Sure improvements could be made, but Microsoft is just trying to make a paradigm shift for the sake of a paradigm shift and forcing more people into using .net. Piping objects has some advantages, but so does using regular text. It seems MSH is just an interactive .net shell.Unix scripting btw has gone through several evolutions, each one significantly improving efficiency. I think microsoft is confused because command line scripting is made for administrators, not programmers (even though most programmers probably use it daily)
      Regards,
      Steve

    121. Re: No Thanks by Anonymous Coward · · Score: 0

      Despite what Redmond might say or do, Unix *is* obsolete. It's a fucking sad time we live in when a clone of a dinosaur OS like Unix is considered the best around (whether you're on that Mac OS X zealotry side or the Linux/BSD zealotry side). It was shit when it was born and it's shit now. Get over your fucking ancient OS and realize there have been better ways for decades now and that no one (not even open source) cares to actually innovate.. or at the very fucking least, they refuse to clone *good* operating systems.

    122. Re: No Thanks by fingerfucker · · Score: 1

      The vast majority of software running on a Windows platform was not written with command line operability or scripting in mind.

      The vast majority of software running on Windows requires interactivity with the user. Running such software in the command-line-style pipelining mode is therefore irrelevant.

      If you want to automate some of those software packages, the object models are out there. E.g. the entire MS Office suite is built upon a set of objects that you can script.

      If you cared enough to get out of the box when thinking about the command line and actually listened to what Jeffery Snover says in the "Monad Revised" interview, you would realize one important innovation that they are bringing with Monad.

      In Unix/Linux command line automation, you end up calling commands A | B | C | .... Often, B has to be a funky Perl script because A produces text output and you need to transform it so that C accepts data in the correct format. So your B is all about assumptions: "hey, so xyz will be 27th column, abc is part of this other token, now let me pray there is no tab delimiter in here, ..."

      With Monad, you will be able to pipe entire objects, which are much easier to deal with, since they are programmatically explorable.

      And to depart from non-mainstream scripting like WSH and WMI, Microsoft has designed the scripting syntax for Monad to be very close to C#, thereby allowing the scripter to actually be on a learning curve towards C# (in Monad, you have the whole CLI accessible), which also strengthens their position when it comes to the widespread usage of the .NET platform and C#.

      The good example that Jeffrey Snover used was this: I have x servers, and one is behaving weirdly. Let me grab a list of processes, get them by name and do a diff on their processor time.

      Now in Unix/Linux, you would probably have a hard time doing this, especially due to the fact that all you'll be doing in your script is trying to get the damn textual output from the 'ps' process to show/format/group right and then doing a textual diff. And if you wanted to present results in a different format, now you have to transform the output of that diff... what a mess...

    123. Re: No Thanks by Anonymous Coward · · Score: 0

      You assume they're trying to reinvent *nix, rather than build something better.

      Not not "they are trying to", but "they are condemned to". They may be trying to make it better than a unix shell, in the same way that they were trying to make NT "a better unix than unix".

      "Poorly".

    124. Re: No Thanks by tfl · · Score: 1

      An interesting point of view. If you look at the Unix shell, there are some really great aspects, but some really horrible ones too. The concept of the pipeline is fantastic, but having to do prayer based parsing on the raw text output is a pain. So in this case, MS has undetstood Unix very well, and has gone one better. Rather than just sticking with what you know, why not try it?

    125. Re: No Thanks by stor · · Score: 1

      Hey dude,

      I bought SFU on behalf of a company a few years ago when it was a charge-for product. It wasn't like MacOS-X my friend. It seemed a bit half-assed and cobbled together to tell you the truth. In it's defence however it's supposed to be 4.4BSD-Lite based software (correct me if i'm wrong).

      Maybe it's a lot better now. I ought to download it sometime to check. The NFS client could be useful. I seem to recall sucky NFS behaviour though. I remember because NFS support was the reason we bought it. Sorry my memory is hazy over that one... so many other problems to deal with since then ;)

      Of course, that was one of the guiding priciples behind Windows NT--a microkernel platform upon which several different standard OS APIs could be implemented.

      Awesome! Pity that Windows is the least compatible platform on the planet with such a wonderful foundation to build on.

      You need to start looking at everything out there, and stopped being brainwashed by the Linux/MacOS zealots!

      LOL. I admin plenty of platforms =) I deploy what needs to be deployed.

      Cheers
      Stor

      --
      "Yeah well there's a lot of stuff that should be, but isn't"
    126. Re: No Thanks by The+Original+Yama · · Score: 1

      " In other words, this is the Posix API implemented on top of a microkernel. Sounds a lot like your beloved Mac OS-X to me. Of course, that was one of the guiding priciples behind Windows NT--a microkernel platform upon which several different standard OS APIs could be implemented. "

      NT does not have a microkernel. It did once-upon-a-time, but it hasn't for many years.

  2. 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:\>


    1. Re:Here's a Screenshot by ShyGuy91284 · · Score: 3, Funny

      Damn, and I was sure they would finally ditch the concept of drive letters this time!!! *Sarcasm*

      --
      In undeveloped countries, the consumer controls the market. In capitalist America, the market controls you.
    2. Re:Here's a Screenshot by Rosco+P.+Coltrane · · Score: 1, Funny

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

      C:\>


      Here's a better screenshot, showing the most useful of all Windows shell commands:

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

      C:\>FORMAT C:

      WARNING, ALL DATA ON NON-REMOVABLE DISK
      DRIVE C: WILL BE LOST!
      Proceed with Format (Y/N)?y

      Checking existing disk format.
      Verifying 40,960M
      Format complete

      Volume label (11 characters, ENTER for none)?

      42,949,672,960 bytes total disk space
      42,949,672,960 byttes available on disk

      32,768 bytes in each allocation unit.
      65,505 allocation units available on disk.

      Volume Serial Number is 3745-19F5

      C:\> bwahahaha!
      Bad command or file name

      --
      "A door is what a dog is perpetually on the wrong side of" - Ogden Nash
    3. Re:Here's a Screenshot by TheAncientHacker · · Score: 1, Informative

      I have no idea what the previous text was but it wasn't the Monad Beta 1 shell. Actually, a real screenshot looks like the following and the concept of drive letters is not really used:

      Microsoft Command Shell
      Copyright (C) 2005 Microsoft Corporation. All rights reserved.

      MSH>_

    4. Re:Here's a Screenshot by Anonymous Coward · · Score: 0

      Monad is just a letter away from Google's new DOS competitor "Gonad".

    5. Re:Here's a Screenshot by mpeg4codec · · Score: 2, Informative

      The previous text is the interface to XP's default shell, cmd.exe.

    6. Re:Here's a Screenshot by Curtman · · Score: 1

      Damn, and I was sure they would finally ditch the concept of drive letters this time!!!

      Yeah, he's got the old alpha. The new shot is over here.

    7. Re:Here's a Screenshot by Glonoinha · · Score: 1, Funny

      The previous text was the original Microsoft DOS shell, an obscure command line interface dating back to the early 80's. Although it had a cult following it never really gained any traction in the business or home / personal computer world as it didn't run any of the Microsoft Office products, couldn't interact with their Windows networks, didn't support Active Directory or any other sort of authentication, and most importantly you couldn't play games on it.

      Come to think of it, other than showing white characters on a black screen, it really didn't have any function.

      Us old-timers aren't surprised that you didn't recognize it - it was actually more of a prototype than a real operating system.

      --
      Glonoinha the MebiByte Slayer
    8. Re:Here's a Screenshot by Planesdragon · · Score: 1

      Just in case folk take the above seriously:

      The MS-DOS shell was the core of the OS beore Windows 95 came about, and before Windows 3.1 took off it WAS the operating system. DOS is what made MS the predominant figure; DOS is what MS licensed to IBM way back in the day.

    9. Re:Here's a Screenshot by Anonymous Coward · · Score: 0

      Jesus, do you really think you need to expain that here?

    10. Re:Here's a Screenshot by Anonymous Coward · · Score: 0

      Dump the stupid drive letter, dammit. I hate drive letters. How hard can a unified file system be? And CMD.EXE is a piece of shit. Ever tried using Microsoft's version of "PUSHD"? What crap! Hard to say whether MSH will be a godsend that Windows-weenies never realized they've needed for 15 years or so... or just another hyper-bloated P.O.S. that will make life even more difficult.

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

    A command line. How innovative!

    1. Re:This is what Microsoft has been "fighting" for! by Klar · · Score: 1

      I just finished reading "In the Beginning... was the Command Line" by Neal Stephenson. If you haven't read it, it is worth the read. After reading it, it made me want to throw away my windows box, and stick with my linux box, heh.

      Here's a quote that I thought fit this article. "The cosmic operating system uses a command line interface."

    2. Re:This is what Microsoft has been "fighting" for! by PakProtector · · Score: 1

      And the 'Cosmic Operating System' is a *BSD derivative!

      See? God is Dead!

      --

      Edward@Tomato - /home/Edward/ man woman
      man: no entry for woman in the manual.
      "Qua!?"

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

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

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

    1. Re:Monad? by teslatug · · Score: 1

      Maybe Miguel will do a port and call it Gono

    2. Re:Monad? by jockm · · Score: 2, Insightful

      And all it took was a simple search to come up with the answer.

      One shell to rule them all...

      --

      What do you know I wrote a novel
    3. Re:Monad? by PhrostyMcByte · · Score: 1

      I'm not sure where they got that name from, the beta site has displayed "Microsoft Command Shell" since it was put up a long time ago. Anyone know where the name Monad comes from?

      As a side note, MSH rocks! The idea that everything is an object that can be piped elsewhere is simple yet adds a world of power.

    4. Re:Monad? by QuestorTapes · · Score: 3, Funny

      Yeah, that name sucks. May as well call it Eunuchs. Oh, wait... ;>

      Most names people make up for products are stupid. This one might not even make it into release.

    5. Re:Monad? by NutscrapeSucks · · Score: 1

      Sounds like a command shell that had one testicle removed.

      I'm guess it'sa joke on UNIX, the OS that had both testicles removed. UNIX++ ?

      --
      Whenever I hear the word 'Innovation', I reach for my pistol.
    6. Re:Monad? by Anonymous Coward · · Score: 0
      Not to be left behind, Google has annouced the imminent beta release of Gonads.

      In soviet russia, Gonads search for you!

      I'll remain anonymous thank you very much

    7. Re:Monad? by gnarlin · · Score: 1

      Is that sarcasm? I have stopped being able to tell anymore due to to much exposure.

      --
      A bad analogy is like a leaky screwdriver.
    8. Re:Monad? by inode_buddha · · Score: 1

      At least UNIX had testicles before MS was even thought of.

      --
      C|N>K
    9. Re:Monad? by Anonymous Coward · · Score: 0

      Or just RTFA

    10. Re:Monad? by Anonymous Coward · · Score: 0

      No, he'll name it with a lantin american coast slang touch: "castrao"

    11. Re:Monad? by skasingularity · · Score: 1

      I dunno, I was thinking just the opposite. Sure, linux has the gonads, but windows has monads.

    12. Re:Monad? by NutscrapeSucks · · Score: 1

      Knee-jerk much? Eunuchs didn't have testicles, that was the whole joke.

      --
      Whenever I hear the word 'Innovation', I reach for my pistol.
    13. Re:Monad? by Tablizer · · Score: 1

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

      Whaddya expect from a company named "Micro Soft"?

    14. Re:Monad? by MikeWeller · · Score: 1

      I believe code names are randomly generated for development, and then the 'real' name is chosen when it is released.

    15. Re:Monad? by Anonymous Coward · · Score: 0

      I think the free software version will be called BASH.

    16. Re:Monad? by Anonymous Coward · · Score: 1, Insightful

      It may be from the way I/O streams are modelled in the functional programming language Haskell, with a bastardised version of "Monads" from category theory. As the major advantage of the command line is composing complex I/O streaming commands, the name may be vaguely relevant.

      And in a few years time, when everyone accuses Open Source of just copying microsoft "innovations" in the CLI world, I would like to remind you that XMLTerm has been around for ages now, so not only has the open source world delivered quality conventional CLIs, it has delivered next-generation integrated CLI+GUI. (and though in its turn, XMLTerm has striking similarities to a Common Lisp CLIM Listener from decades ago...).

      Microsoft are the ones playing catch-up here: but that doesn't mean one should rest on one's laurels. While MS might no longer attract the best brains in the industry (did it ever?), they can keep throwing their stock-scam money at a problem for a very long time.

    17. Re:Monad? by tricore · · Score: 1

      I think the name Monad is supposed to be a pun. There are several possible reasons why they might have chosen Monad, but given that we're in the realm of computers I'm guessing their using the term in reference to functional programming languages. In some functional languages, it is difficult to impossible to specify when an action is actually going to be taken. For pure functions in the sense that they merely evaluate to a result, this doesn't matter, but when we have side affects (for example user IO) this can be a problem. Monads are a concept used to wrap such functionality so that it's possible to specify when it happens... a Shell of course, is the user's interface to the system. get it?... heh, heh... yeah.

    18. Re:Monad? by Almost-Retired · · Score: 1

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

      Probably because knowing M$ and their attitude vis-a-vis their IP , I'd suspect that it will be very well filtered to "prevent the user from damaging his (oops, thats actually 'my' in the M$ tense. Get over it windows lusers, it hasn't been yours in 10+ years) system."

      In other words, it will have been both partially castrated as you suggest, but the remaining testicle will have been disabled via the equ of a coded vasectomy.

      Remember, you first read it here on /.

      --
      Cheers, Gene
      "There are four boxes to be used in defense of liberty:
      soap, ballot, jury, and ammo. Please use in that order."
      -Ed Howdershelt (Author)

    19. Re:Monad? by Osty · · Score: 1

      I'm not sure where they got that name from, the beta site has displayed "Microsoft Command Shell" since it was put up a long time ago. Anyone know where the name Monad comes from?

      It's an internal codename, like Whistler (shipped as Windows XP), Everett (shipped as Visual Studio .NET 2003), or Yukon (will ship as "SQL Server XXXX" where "XXXX" is some year, probably 2005 or 2006). You can bet that when it ships the name Monad will be completely gone except in the minds of the users (people still use "Everett" to distinguish Visual Studio .NET 2003 and .NET 1.1 from the upcoming "Whidbey" release, or Visual Studio 2005 and .NET 2.0).

    20. Re:Monad? by Afrosheen · · Score: 1

      More appropriately, he'll call it "guano".

      For the spanish-ly impaired, here's a definition.

    21. Re:Monad? by Anonymous Coward · · Score: 0

      Nah, surely he'd call it gonad.

    22. Re:Monad? by darkonc · · Score: 1
      While MS might no longer attract the best brains in the industry (did it ever?), they can keep throwing their stock-scam money at a problem for a very long time.

      Oh, they have.. Attracted them, captured them, and devoured them.

      Brains! Need more Braaaaiiins!
      (should I insert a "Bwahahahaha!" here?)
      --
      Sometimes boldness is in fashion. Sometimes only the brave will be bold.
    23. Re:Monad? by dubdays · · Score: 2, Funny

      Sounds like a command shell that had one testicle removed.

      No, it's plural. You know, like:

      "Yo, you ain't no playa. I got mo nad than you, yo."

    24. Re:Monad? by Jah-Wren+Ryel · · Score: 1

      What kind of name is that?

      Microsoft
      Only
      .NET.Shell
      ActiveShell
      DirectShell

      --
      When information is power, privacy is freedom.
    25. Re:Monad? by spectre_240sx · · Score: 1

      Uhhh... software for micro computers, obviously. Duh.

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

    1. Re:monad by Anonymous Coward · · Score: 0

      Whoa, horsie! Users don't know what applications are "object oriented" in implementation, which are functionally programmed, and which are written in good ole procedural COBOL. You may have an issue with a lust for buzzword compliance. If you are talking about "shell as programming language", it's much more fun to not write code in shell and switch to Python ... or Ruby.

    2. Re:monad by Marko+DeBeeste · · Score: 1

      Oops, fisted again my M$

      --
      Faith: n. -- That human impulse that drives them to steal appliances when the power goes out
    3. Re:monad by Compholio · · Score: 1, Informative

      All the others use strings for piping.

      If you read the article (Wiki) you'd see that Monad does too, it just automatically converts them before passing them off to the program (like PHP does with all of its variables). We'll have to wait and see if their approach is any good - there's a lot of flexibility in grep and awk that I don't see MS duplicating to occur automagically.

    4. Re:monad by Atzanteol · · Score: 0

      It actually looks a lot more like Perl or Python than a typical shell. In which case Perl or Python have had objects for years.

      But who cares? It actually looks like a decent scripting language. Shame MS has such a big "Not Invented Here" syndrome that they can't accept other languages into their OS that they haven't written themselves...

      --
      "Ignorance more frequently begets confidence than does knowledge"

      - Charles Darwin
    5. Re:monad by zurab · · Score: 1
      It is , I beleive, the fist object oriented shell.

      No, it's not. Windows itself has had WSH for awhile now (since Windows 98?). You can use VBScript or JScript with that environment with the ability to install other scripting engines. It's definitely an interesting concept, but it's just that it became so much of a security nightmare, a lot of people advise to simply have it turned off.
    6. Re:monad by jeanicinq · · Score: 1

      It is , I beleive, the fist object oriented shell.

      Definitely not. Atomatrix started in the 1980's. It expands the oo-shell with a natural language interface, but the oo-shell is still accessible from the interface. It's gone through various rewrites and periods of inactivity. Even before that, there were variants of MOO.

    7. Re:monad by Ravatar · · Score: 1

      The MSH backend is .NET and C#, so I'm really doubting that flexibility is a problem. If you don't like their grep alternative, create your own.

    8. Re:monad by Naikrovek · · Score: 1

      windows scripting host is not a shell.

    9. Re:monad by SA+Stevens · · Score: 1

      Shame MS has such a big "Not Invented Here" syndrome that they can't accept other languages into their OS that they haven't written themselves...

      Wow. After reading your comment, that old looseleaf binder labeled 'Microsoft C' that I've had on my bookshelf for 20+ years seems to have completely disappeared.

    10. Re:monad by Atzanteol · · Score: 1

      With some exception of course. Jebus, must everything be taken too literally around here?

      --
      "Ignorance more frequently begets confidence than does knowledge"

      - Charles Darwin
    11. Re:monad by Anonymous Coward · · Score: 0

      Typically 13 years old are like that.

    12. Re:monad by plalonde2 · · Score: 1
      Um, Try Oberon, or even Smalltalk in any decent implementation. Object-oriented interactive shells are pretty common, and pretty much all of them provide interfaces the the system.

      Hell, some of them even support pointy-clicky stuff.

    13. Re:monad by Plaid+Phantom · · Score: 1

      Of course. That's the only way people get any drama on the inter nets.

      --
      All comments are properties and trademarks of the voices in my head. Not like I'm gonna claim them.
    14. Re:monad by fyrie · · Score: 1

      Yes, the shell syntax itself is object oriented and IIRC you can instantiate clr objects and manipulate system objects. The channel 9 vids of today and yore go into all of that. I've watched them and imho the monad shell is a different beast than your standard *nix shell.

    15. Re:monad by I'm+Don+Giovanni · · Score: 0, Flamebait

      You made an ignorant statement and got called on it. Now you're whining that someone took your statement "too literally". LOL

      Besides that, your "with some exception" spin holds no water because even one of your cited languages, Python, disproves your point because Microsoft now controls Iron Python. The notion that they can't accept other languages is just ignorant ranting on your part. LOL

      --
      -- "I never gave these stories much credence." - HAL 9000
    16. Re:monad by hitchhacker · · Score: 1


      All the others use strings for piping.

      UNIX/GNU uses pipe(2) for piping.. (suprise). It doesn't care what the data is. So no, unix isn't limited to piping strings. You could pipe something like XML objects if you wanted object oriented piping.

      On a side note, I do think stdio needs a new interface. IMO we need to be able to pipe via a namespace rather than just stdin/stdout/stderr. Imagine mounting your program somewhere on the filesystem/netport and exporting an I/O namespace on to the filesystem.

      -metric

    17. Re:monad by thogard · · Score: 1

      Your not limited to the standard 3 file handles. In complex shell based systems, its common to see scripts passing around half a dozen file handles.

      The problem is that no one ever came up with a good naming convention that works well with the traditional shell syntax.

    18. Re:monad by Anonymous Coward · · Score: 0

      And it took them how long to get that right? Their early C compilers didn't even use C calling convention (one of the reasons for the Pascal calling convention that is still in every windows program today).

      They didn't get their C compiler solid until they released someone that just happened to have the same set of bugs as GCC had at the time.

    19. Re:monad by Atzanteol · · Score: 1

      LOL? Did I post to America on-line by accident? LOL!

      Ignorant ranting... .NET? C#? Visual J++? MSH? Almost all of which are MS replacements for other languages (one being an extension of one)?

      What I meant by 'too literal' stands. One can't make a post on /. without appending a ton of caveats (IANAL, I use Microsoft products but..., By "they do" I mean it "in general", etc.). LOL!

      I honestly didn't know about IronPython. Perhaps you could have found a non-scathing way of bringing it to my attention? But then you wouldn't have that nice feeling of "gotcha!" would you? LOL!

      --
      "Ignorance more frequently begets confidence than does knowledge"

      - Charles Darwin
    20. Re:monad by Feztaa · · Score: 1

      Out of curiosity, would you classify Python's interactive mode as a shell in this sense?

    21. Re:monad by Sinner · · Score: 1

      It is, I believe, the singular form of "gonad".

      --
      fish and pipes
  7. Re:That's all well and good by Saeed+al-Sahaf · · Score: 2, Insightful
    The question is, who would really be interested in it at all?

    Well, Windows network admins? Say what you will about Windows, most of it's true. But lot's of serious companies use it, and some of them even hire smart people to admin their systems. Could be usful for something like that, maybe.

    --
    "Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
  8. Next step... by michelcultivo · · Score: 0, Troll

    ...is copy the kernel from *nix. On this world nothing is created, but all copied.

  9. 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.
    1. Re:I guess the site's running it .... by Anonymous Coward · · Score: 0

      Here is the error I got by visiting. (Ha ha they must be trying to us MS windows as a server OS.)

      We apologize, but an unknown error has occured in the forums.
      This error has been logged.

      Return to the previous page

    2. Re:I guess the site's running it .... by Anonymous Coward · · Score: 0

      Oh please mods don't rate this as Funny... If I see one more friggin' "Guess the site runs on it!" post like this I'm gonna fucking barf...

  10. I don't get it. by thehfctech · · Score: 1, Funny

    Server Error in '/' Application. Runtime Error Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine. Details: To enable the details of this specific error message to be viewable on remote machines, please create a tag within a "web.config" configuration file located in the root directory of the current web application. This tag should then have its "mode" attribute set to "Off". Notes: The current error page you are seeing can be replaced by a custom error page by modifying the "defaultRedirect" attribute of the application's configuration tag to point to a custom error page URL.

    1. Re:I don't get it. by ettlz · · Score: 1

      I went poking around a bit further before the shit hit the fan, and found this little thingy called "CrashNot" (dunno if it's genuine, www.crashnot.com doesn't work), the self-styled Counter-Slashdot. It's a chuckle.

      But I like the idea of a Bugzilla for Microsoft products.

  11. DOS by Anonymous Coward · · Score: 0

    So, DOS gets a new face huh.

  12. 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 SnprBoB86 · · Score: 3, Insightful

      There autocompletetion as well as an abreviation usage system. If you still don't like the verbose names, alias them.

      It's that simple.

      Short, cryptic names hinder usablity by greatly increasing the learning curve. "get-process" is far more intuitive than "ps", as "where" or "filter" is far more intuitive than "grep". If you find yourself typing "get-process" a million times, learn to type faster or alias it to something shorter.

      --
      http://brandonbloom.name
    2. Re:First impressions by Tim+C · · Score: 1

      If you find yourself typing "get-process" a million times, learn to type faster or alias it to something shorter.

      Or learn to type just enough of it then hit tab for autocompletion to work its magic.

      That's one thing I hate about most anti-Java rants, they always pick on the verbosity of the API, ignoring the fact that any decent IDE (and that includes vim!) will allow you to type a few characters then autocomplete it. Same thing will be/is true of MSH.

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

    4. Re:First impressions by killjoe · · Score: 1

      It will probably fail because MS has been telling all their sysadmins that command lines are worthless and that the only people who use command lines are communist dirty hippies. After decades of telling their users that they don't need a command line, that the GUI is better then the command line, that command lines are dangerous I don't see how they will change all those minds. What are they going to say? "Sorry we have been lying to you for a decade"?

      --
      evil is as evil does
    5. 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.
    6. Re:First impressions by Anonymous Coward · · Score: 0

      not so. grep means grep. ps means ps.

      'where' or 'filter' have a multitude of english meanings, all of which serve to confuse the exact behaviour they have.

      yes, to learn ps and grep you have to learn 2 new words (although they have english roots to help remember them).

      to learn what where and filter do, you have to take clues from their meanings, forget all their other meanings, and then also remember what they do. that is much harder.

    7. Re:First impressions by teslatug · · Score: 1

      You can have shorthands for the commands. Longhand is good for scripts as it improves readability. For everyday use, short aliases are just fine.

    8. Re:First impressions by Ingolfke · · Score: 3, Insightful

      Both must be learned.

      Both must be learned and remembered. Longer names allow for an easier to remember naming convention that can then help you remember or find the command you wanted. Two letter commands are certainly easier to type, but as others have mentioned the command completion in the interactive shell should take care of that.

    9. Re:First impressions by Nasarius · · Score: 1
      As for the suggestion to alias commands so you don't have to type as much - wow, that's even more braindead.

      I don't know. I don't function properly without my l='ls -al -h --color' alias. That's one of the many reasons I carry my .bashrc wherever I go.

      And yes, claiming that "get-process" or "where" is intuitive is simply asinine, or a gross misunderstanding of the word intuitive.

      --
      LOAD "SIG",8,1
    10. 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
    11. Re:First impressions by Compenguin · · Score: 1

      s/command\ line/Intel/g | s/GUI/PPC/g | s/MS/Apple/g

    12. Re:First impressions by Anonymous Coward · · Score: 0

      > If you still don't like the verbose names, alias
      > them.

      That's great until you encounter another PC that isn't setup with all your aliases.

    13. Re:First impressions by Dillusionary · · Score: 1

      I dunno, make sense to me.

      ps = process
      which = which one
      whereis = where is this file
      find = find me this
      ls = list
      man = manual
      grep = g/re/p
      rm = remove
      rmdir = remove dir
      kill = kill this pid

      The more you use *nix the more it will start to make sense, but yes it all needs to be learned. I prefer the short commands.
      But you can alias it to...

      alias get-process-list='ps'
      alias a_long_ass_command_to_execute='grep'

    14. Re:First impressions by Osty · · Score: 1

      Then use ps, it's a built-in alias for get-process.

      "Built-in" by being set in the default profile.msh, sure. If you want to use ps for something else, you can always remove the default aliasing. Sort of like how many linux distros give you a "built-in" alias like 'll' for 'ls -l'. It's not built-in, but a convenience alias added by default that you can get rid of later if you like.

    15. Re:First impressions by Liquidrage · · Score: 1

      Yes, it is. Obviously you're either being negative due to a bias or not speaking from experience. I'll assume the former.

      True, either way someone will need to know the command when writing it themselves and neither way would qualify as a priori knowledge.

      However, "get-process" is far more obvious as to intent, most likely easier to remember, and will be much more obvious when read in it's normal context (meaning there's a lot commands and other junk written around it). A complete newcomer could read someone else's script and know exactly was "get-process" meant, where as "ps" might not be clear.

      This isn't new thinking here. Would you name variables a, aa, b, BB, etc....? I suppose you would based on your statement above. Myself, I'll take the name who's intent is obvious any day of the week. Especially when you can alias the commands yourself should you want to.

    16. Re:First impressions by nEoN+nOoDlE · · Score: 1

      get-process is more intuitive because if I watch someone typing it over their shoulder, I'm more likely to know what it's doing and thus remember it, than if they typed "ps." When I'm at my desk in the new shell and I'm thinking "Ok, how do I get this process?" Which do you think would be easier to remember? I'll take the 11-character command with a 2 character shortcut any day

      --
      Don't trust a bull's horn, a doberman's tooth, a runaway horse or me.
    17. Re:First impressions by Anonymous Coward · · Score: 0

      Believe me, it only makes sense because you've spent a long time in the environment. Someone bred on MSH would think that environment makes a lot more sense, and would think the cryptic unix names are silly and clumsy.

      Besides, given that this thing passes around objects instead of strings, I'm thinking it will be dramatically more powerful than the UNIX shell when it is put out there in final form.

      I have to give props to MS. They looked at the UNIX shell, and they made something better. I don't like it, but I feel silly denying it.

    18. Re:First impressions by fm6 · · Score: 1
      What are they going to say? "Sorry we have been lying to you for a decade"?
      Pretty much. They'll just put it more tactfully than that. It's called "spin".
    19. Re:First impressions by eikonos · · Score: 1

      And when everyone creates a slightly different short form as their alias, how will you use it when you're not at your own machine? It's better to start out with a common set of short forms that everyone uses and learn them even if it takes a bit longer.

    20. Re:First impressions by Alioth · · Score: 1

      I know all about the aliases. I'm talking about the default output from some of these commands. Try typing 'ls' some time - the output is utterly useless for any directory with more than 2 files.

    21. Re:First impressions by Al+Dimond · · Score: 1

      get-process might be more intuitive than ps (well maybe it should be get-processes or something... I don't know, I saw someone use ps once and instantly understood), but once you alias it to your own favorite quick thing to type, you'll still have to type get-process on other computers that you happen to use. ps is a nice short command that works on all *nix boxes, not just a few that you happen to manage.

    22. Re:First impressions by SharpFang · · Score: 1

      process, process, let's try. pr, pc, ps. Okay, it's ps.
      Now what about msh? show-process. list-process. show_process. list_process. display_process. display-process. displayProcess. view-process. see-process. print-process output-process. fuck-process, argh, where's the manual?!

      --
      45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
    23. Re:First impressions by Anonymous Coward · · Score: 0

      Skimming a list it's easier to guess what the command does, and searching for "process" would bring up a command "get-process" but not "ps"

    24. Re:First impressions by value_added · · Score: 1

      Personally, I find it both your opinion and reasoning somewhere between laughable and uninformed. But putting that aide for the moment (cuz we're talking about Windows) and consider the following:

      LmHosts (TCP/IP NetBIOS Helper Service)
      postmaster (postmaster)
      PlugPlay (Plug and Play)
      PolicyAgent (IPSEC Policy Agent)
      RasMan (Remote Access Connection Manager)
      Spooler (Print Spooler)
      TrkWks (Distributed Link Tracking Client)
      Wmi (Windows Management Instrumentation Driver Extensions)

      Now let's say you go about administering a Windows system using the command-line only, tell us which of the above service names are you typing in? Which do you have memorised? Or do you have any? And which service names bear any resemblance to name of the actual executable (when applicable) responsible for providing the service? Forgetting that Windows is case-insensitive but case-preserving, let us know how your typing accuracy and speed is enhanced when typing long names using both upper and lower case.

      SnprBoB86@work
      $ net start Windows Management Instrumentation Drive Extensions

      ???

      Didn't think so.

      Add to this simple but bizarro example the poorly documented quoting/escaping voodoo required for anything more than the trivial execution of a single command, muddled even further with the all-purpose 'net' command (which isn't really a command) and the 'start' command (which is a command, but not in the context of using it with the 'net' command), and the truth soon becomes obvious:

      The folks at Microsoft have no concept how to use the command-line, and if the wildly varying command syntax constructed from a tortured mix of spaces, slashes, dashes, colons and backslashes is any indication, they most likely wouldn't know how to write a program that is made to be run from it.

    25. Re:First impressions by sirshannon · · Score: 1

      bingo. If I had mod points, you'd get an "insightful" from me.

      It took me a few years to finally realize that using longer names that read the same way I think/talk is pretty much the only way I can remember those names later.

      I assume that is why CSS has "background-color" instead of "bgcolor". It is tremendously easier to remember that you want to use "background-color" to change the background color instead of trying to remember what cool, clever abbreviation scheme is being used.

      Logical naming rules that can be thought, spoken, and written without remember a ton of arbitrary rules makes my life SO much easier. True, "get-process" uses an arbitrary rule for naming, but when you start abbreviating everything, each name gets a different arbitrary rule that will vary drastically from person to person.

      However, for all the non-English speaking developers out there, I apologize.

    26. Re:First impressions by Anonymous Coward · · Score: 0

      Although by using a logical naming system, you can guess at the names and 90% of the time have them work. For example, in Java you have 'toString(), toInt() etc. Guess how you convert a variable to a long? It is much easier to remember and guess at when there is a elegant naming system, you only need to learn the naming system, then you know most of the commands or can intelligently guess at them, and remember them.

    27. Re:First impressions by Anonymous Coward · · Score: 0

      err. ok toLong is wrong here, you can see I havent used Java in a while, but you get the idea.

    28. Re:First impressions by Anonymous Coward · · Score: 0

      Haha!

      And one of these days we will be able to do it the same way as in the 80's computer moves:

      c:\> open all hidden files

      Bah!

    29. Re:First impressions by Ravatar · · Score: 1

      By built-in I meant provided with the vanilla MSH. Sorry for any confusion.

    30. Re:First impressions by emil.ede · · Score: 1

      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.

      no, no it's not. atleast not for me. I always keep forgetting the name of commands with unlogic names like ps, df, etc. I can't see why there not is a long full name and a short name avaliable for all basic commands.

    31. Re:First impressions by Arker · · Score: 1

      Don't worry. If it's ever finished and shipped, JPSoft will have a usable replacement for it too, as they've done with every previous MS shell.

      --
      =-=-=-=-=-=-=-=-=-=-=-=-=-=-
      Friends don't let friends enable ecmascript.
    32. Re:First impressions by drsmithy · · Score: 1
      Add to this simple but bizarro example the poorly documented quoting/escaping voodoo required for anything more than the trivial execution of a single command [...]

      The folks at Microsoft have no concept how to use the command-line, and if the wildly varying command syntax constructed from a tortured mix of spaces, slashes, dashes, colons and backslashes is any indication [...]

      I hope you're not trying to suggest the Unix commandline is at all consistent, logical or intuitive ?

    33. Re:First impressions by Jugalator · · Score: 1

      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.

      On the other hand, Monad is very consistent in its naming scheme, so there are other "get-" commands as well.

      --
      Beware: In C++, your friends can see your privates!
    34. Re:First impressions by nachoboy · · Score: 2, Informative
      It will probably fail because MS has been telling all their sysadmins that command lines are worthless and that the only people who use command lines are communist dirty hippies. After decades of telling their users that they don't need a command line, that the GUI is better then the command line, that command lines are dangerous I don't see how they will change all those minds. What are they going to say? "Sorry we have been lying to you for a decade"?

      Maybe it's because I come from a more Microsoft- than *nix- centric background, but since where and when have Microsoft ever made any sort of statement even resembling anything close to what you've said above? Sysadmins have plenty of tools at their disposal. See %windir%\help\ntcmds.chm for tons more info than I can provide here.

      I use Windows at home and at work and find the command line environment very powerful and usable. I admin my machines (3 at home, 3 at work, 1 laptop, and several remote family member's pc's) almost exclusively via the command line. The set of default tools has increased dramatically in the last 10 years, and any Microsoft OS released in the last 5 years includes all of the following:

      sc - service controller for starting/stopping/managing services on local or remote machines
      diskpart - create/modify/delete local disk partitions (including advanced configurations like RAID arrays)
      bootcfg - modify boot entries
      fsutil - file system tools (reparse points, sparse files, hardlinks)
      netsh* - network configuration tool to manage interfaces, protocols, routes, firewall, etc.
      wmic - complete WMI (Windows Management Instrumentation) control
      cacls* - modify NTFS permissions
      systeminfo - query basic configuration information for local or remote machine
      findstr - text searching, and yes, it handles regular expressions
      msiexec* - not strictly a command line tool, but supports installation/configuration/uninstall of any .MSI package.
      reg - modify the registry (including online and offline hives, and other users' hives)

      I do find a couple of things lacking, so I customize all my Windows installs to include the following (all free except for the last, which requires that you own WinZip):

      File Hashing: By the time Microsoft came out with fciv, I was already sold on fsum.
      HTTP Downloads: I use wget for Windows.
      Patch Scanning: I use MBSA for an instant report of missing patches so I can avoid Windows Update.
      cab Compression Tools: Uncompression is supported natively via "expand"; need cabarc from the support tools to compress.
      zip Compression Tools: Free add-on to Winzip works here.

      Most people I know (Windows and *nix users alike) are very uninformed about Windows command line capabilities. However, this does in any way mean that the command line is crippled, or unable to perform the same admin tasks that are possible via the GUI.



      *also existed in Win2000 or earlier

    35. Re:First impressions by dcam · · Score: 2, Insightful

      If you still don't like the verbose names, alias them.

      It's that simple.


      This is not a good argument. Default names become the standard. There are many reasons for this, but the top ones:
      1. You go to someone else's machine, they have a different set of aliases
      2. Re-install, have to realias it.

      Good defaults are important.

      --
      meh
    36. Re:First impressions by leonard_chung · · Score: 3, Interesting
      The intent behind the longer names is really for initial learning curve and scriptability.

      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

    37. Re:First impressions by spongman · · Score: 1
      that's ok, we apologise for your confusion.

      it's built in to the vanilla msh. it ships with it. you don't have to do anything (beyond install msh) to use it. it's a default. etc...

    38. Re:First impressions by SnprBoB86 · · Score: 1

      1. You go to someone else's machine, they have a different set of aliases

      If you plan on doing some heavy command line work on someone elses computer, bring your profile file. It's a tiny text file that could easily be kept in a public place.

      2. Re-install, have to realias it.

      No, you don't. Your aliases are maintained seperately. See Bash and .bashrc

      --
      http://brandonbloom.name
    39. Re:First impressions by GNUALMAFUERTE · · Score: 1

      Yes, but computing is not for dumbs. Would you trust a person that can't remember a 2 leter command to be your sysadmin?.
      The point is, the problems that you have to solve through the use of computers are not simple, and the main tasks involved in solving them aren't easy either. If you think Emacs is to hard to use, then you don't really need Emacs, since, if the editor seems to hard for you, don't even talk about C Code. People trash-talk constantly about old-school software, saying it's hard or unusable, read: Sendmail, Emacs, C, Bash, etc. Some people just extends that to Unix as a whole. This tools are very powerfull, and most of them has been here for over 30 years. Hackers allready know them, and they are the way they are, because the kind of people that should be in front of a computer coding, usually thinks like that, the software i mentioned, is software that has an interface designed to be used by MACHINES, and Hackers tend to think like machines. I Do, in many ways, only that we are creative machines. So, if you have a "programmer", that complains about the interface of the tools we have used for years, the same tools that has been used to develop all the software we currently have, then that person doesn't think like a Hacker, he is a user. If he can't think like a coder, then he can't expect us to adapt our compilers, editors, debuggers, etc. to his stupid point and click interface, if he thinks like a user, then BE just a user.
      The problem in the windows world is that most windows programmers are users that wanted to code. In Unix, lusers are lusers, and Hackers are Hackers. That's why Unix works, and Windows is what it is.

      --
      WTF am I doing replying to an AC at 5 A.M on a Friday night?
    40. Re:First impressions by Des+Herriott · · Score: 1

      However, "get-process" is far more obvious as to intent

      Really? "get-process" sounds like a command to get (or even create?) a process, not to list the current processes.

      But who cares? Like I said already, you need to learn what "ps" means, and you need to learn what "get-process" does, and in both cases you have to remember the command. It's "ps", not "pr" or "lp", and it's "get-process", not "list-process" or even "list-processes". Neither is any more intuitive or memorable than the other, and based on that, I go for terseness over verbosity. I guess a lot of people disagree.

      But, if someone can't even remember a basic 2 (or 11!) letter command, then they might as well hand in their sysadmin licence and go back to being l33t at Counterstrike, IMHO.

    41. Re:First impressions by dcam · · Score: 1

      If you plan on doing some heavy command line work on someone elses computer, bring your profile file. It's a tiny text file that could easily be kept in a public place.

      First off, you don't often plan to do this kind of work. In the course of general life these things can sneak up on you. So I would need to carry around your profile file everywhere. Probably on floppy, USB key and CD, so as to have it available on all machines. And I'd need to be able to transfer it over terminal service to whatever server I was working on at the time.

      Ok so I am being a little extreme, but I do have better things to do in life than carry around the aliases monad. What if I had to do this for each application I used?

      2. Re-install, have to realias it.

      No, you don't. Your aliases are maintained seperately. See Bash and .bashrc


      You are somehow suggesting that when I reformat and re-install, monad keeps my settings?

      The point I am making is that good defaults are *very* important, because for most people that is all they will use, and in general it is often inconvenient to use anything other than the defaults.

      --
      meh
  13. 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 Saeed+al-Sahaf · · Score: 1

      Haven't tried it, eh? It shows...

      --
      "Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
    2. Re:whoosh! by Planesdragon · · Score: 1

      The Unix shell is the implementation of the Unix philosophy of small parts working together.

      Which KDE, Linux, and Gnome have perserved so very, very well.

    3. 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
    4. Re:whoosh! by Anonymous Coward · · Score: 0
      Which KDE, Linux, and Gnome have perserved so very, very well.

      Yes. They have. Was that intended as sarcasm?

    5. Re:whoosh! by diegocgteleline.es · · Score: 3, Interesting

      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.

    6. Re:whoosh! by lheal · · Score: 0

      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.

      It will be interesting to see when fully operational.

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

      gtk, k-widgets, linux not using a microkernel?

      --
      HI O WISE PRINCE. WHT TOOK U SO DAM LONG?
    8. Re:whoosh! by brpr · · Score: 1

      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.

      It will be much more efficient than running regular expressins over unformatted text streams. Instead of the data being formatted and then parsed every time it's passed from one process to another, the data can be passed and accessed directly with no overhead. If you think about it, it will be a big improvement in terms of efficiency (not that efficiency matters in a command script language anyway...)

      --
      Freedom is not increased by mere diminuation of government. Anarchy is freedom for the strong and slavery for the weak.
    9. Re:whoosh! by Soul-Burn666 · · Score: 1

      Wow that looks a hell lot like SQL.
      Replace "get-process" with "SELECT * FROM processes".
      Replace "get-member m" with "SELECT m FROM...".
      Replace "where" with.. well, "WHERE"
      and so on...

      Not that it's inherently bad...

      --
      ^_^
    10. Re:whoosh! by Beek · · Score: 1

      You honestly think performance will be an issue on a 3 ghz machine?

      LOL, in fact LMAO

    11. Re:whoosh! by lheal · · Score: 1
      You honestly think performance will be an issue on a 3 ghz machine?

      Yes, I do. Performance is always an issue, and our perception of it tends to outpace its improvement. We once thought 10 Mhz was fast, and 16Mhz was "screaming".

      --
      Raise your children as if you were teaching them to raise your grandchildren, because you are.
    12. Re:whoosh! by Anonymous Coward · · Score: 0

      not in a bloody shell script though. easy to use, safe and flexible counts for one hell of a lot of wasted cycles in my book (not that MSH looks like it will have any of that in spades either).

    13. Re:whoosh! by lheal · · Score: 1
      the data can be passed and accessed directly with no overhead.

      No, the objects will have to be rebuilt for each and every use. But suppose they hang around.

      Even just giving a cmdlet the location of a bunch of objects in memory and having it call their methods one by one will take time, much more time than running regular expressions over text streams.

      But I wish them well.

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

      So who determines what information you want accessible in what objects? I thought that was the power of hte unix shells. You could pull information from another process however you like.

    15. Re:whoosh! by Anonymous Coward · · Score: 0

      So will there still be some kind of text interface between programs, or does everything involve these objects? This seems like too much integration; what if you want to write your own tool? Will it have to obey the object interface?

    16. 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.
    17. Re:whoosh! by killjoe · · Score: 1

      How is this different then firing up ruby or python and doing the same thing?

      --
      evil is as evil does
    18. Re:whoosh! by AlexMax2742 · · Score: 1

      That seems like a pretty closed minded way to think about things. You're pretty much convinced that Linux has the absolute best way of doing anything, and therefore there is no way that Microsoft can ever catch up without copying ideas.

      Think about us Windows users. Linux does not suit my needs (mainly because I love gaming, and Linux support for games seems spotty at best, no matter if it be through ports or winex), but still I miss a few of the features of Linux such as a fully fleshed out command line interface. What exactly am I supposed to do?

      I for one can't wait for MSH. So long, DOS prompt.

      --
      I'm the guy with the unpopular opinion
    19. 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!
    20. Re:whoosh! by Anonymous Coward · · Score: 0

      What strange world do you live in where a method call is more expensive than parsing something with a regex?

    21. Re:whoosh! by teslatug · · Score: 1

      Umm, it's faster to build. How long would it take you build SQL-like commands with python/ruby that are generic enough to not have to rewrite for each output?

    22. Re:whoosh! by eyeye · · Score: 1

      You have a magical 3ghz CPU that processes everything instantly? Or a retarded brain? Let me guess - its the latter.

      --
      Bush and Blair ate my sig!
    23. Re:whoosh! by Anonymous Coward · · Score: 0

      It's obvious that you know absolutely nothing about the current Windows shell, so STFU.

    24. Re:whoosh! by Eudial · · Score: 1

      ... but still I miss a few of the features of Linux such as a fully fleshed out command line interface. What exactly am I supposed to do?

      http://www.cygwin.com/

      --
      GAAH! MY PRINTER IS ON FIRE!!! PUT IT OUT! PUT IT OUT!
    25. Re:whoosh! by killjoe · · Score: 1

      I guess I am missing the point. I fire up python and ruby all the time to do shell tasks and I find myself incredibly productive. Are you saying that writing a new regexp is cumbersome?

      --
      evil is as evil does
    26. Re:whoosh! by fbform · · Score: 1
      ps vOr | awk '{if ($8 > 15000) print $_ }'

      Shorter version:
      ps vOr | awk '$8 > 15000'
      (The default action for awk is to print the whole line).
      --
      Time flies like an arrow. Fruit flies like a banana.
    27. Re:whoosh! by EvanED · · Score: 1

      I do some work just fine on an Athlon 500. This computer is about 6 years old, and it suits my purposes.

    28. Re:whoosh! by brpr · · Score: 2, Insightful

      No, the objects will have to be rebuilt for each and every use

      What on Earth do you mean by this? The objects will not have to be rebuilt every time one of their methods is called. Perhaps you mean something else, but it's hard to see what that might be.

      Even just giving a cmdlet the location of a bunch of objects in memory and having it call their methods one by one will take time, much more time than running regular expressions over text streams.

      Rubbish. A regexp parse itself will make many method/function calls. And why would you need to call the object's methods "one by one"? Surely you would only be interested in one or two of its methods?

      --
      Freedom is not increased by mere diminuation of government. Anarchy is freedom for the strong and slavery for the weak.
    29. Re:whoosh! by SA+Stevens · · Score: 1

      We're talking about a USER interface, not programming interfaces.

    30. Re:whoosh! by julesh · · Score: 1

      It looks a hell of a lot more like proper relational calculus than SQL -- and it should; the operations that it's designed to perform (taking tablse of objects, and filtering them so that you just have what you want) are the same problems that relational calculus was designed for.

      It's a hell of a lot more flexible than SQL which is severely restricted by its arcane syntax.

    31. Re:whoosh! by julesh · · Score: 1

      The difference is that there are a whole bunch of standard data providers and consumers ("commandlets") distributed with the OS to make certain jobs easier. Plus, as it will be installed on every OS installation, it will (hopefully) become customary for app vendors who write programs that can provide tabular data to write them as commandlets, so you can easily access those. Because everything's based on structured data, it's much simpler than parsing out of a text format (that may not be very well defined) as you would have to when trying to interface with something that doesn't come with a python/ruby module.

      Of course, the entire framework's written in .NET, so you ought to be able to access those same commandlets with IronPython, which is a plus point for those of us who know the language. :)

    32. Re:whoosh! by julesh · · Score: 2, Insightful

      I thought it was fairly obvious -- this works pretty much like piping data, except that instead of throwing text around, they're throwing structured objects instead.

      So, in this case, the "get-process" commandlet's author determines what data is available in its output (same as the "ps" author determined the availble information under Unix).

      Basically, it's just as flexible as text output and parsing, without the overhead of writing and debugging regexps/awk scripts to get the data you want, as it's available in a much easier-to-use way based on object structure.

    33. Re:whoosh! by phiwum · · Score: 1

      If you absolutely -must- sort out those that have less than n mem usage, try
      $ ps vOr | awk '{if ($8 > 15000) print $_ }'


      Be fair, now. If your skill with bash is anything like mine (it's not -- I don't know awk), you have to add in keypresses needed to write that. For me, that includes "man ps" (you used flags I've never used). Let's skip the "awk" command, since it would take too many keystrokes for me to learn awk so that I'd write that. Assuming I knew awk, I'd still have to execute the ps command to figure which field is relevant.

      The code snippet he wrote was lengthier (much too long for geek kudos) but I bet I have a better chance to write it correctly on the first try.

      (As a matter of personal taste, I wager that Bash is more to my liking than MSH. But we should count the keystrokes needed to learn how to write the commandline, too.)

      --
      Phiwum's law: anyone that names an obvious law after himself and then puts it in his own sig is just pathetic.
    34. Re:whoosh! by Anonymous Coward · · Score: 0

      The real world.

      How many method invocations will your structured 10kb of data require to find the relevant data items? Think about it--there's a reason xml stream parsers are much faster than parsers which load the entire xml doc into an object model.

    35. Re:whoosh! by Osty · · Score: 1

      If you absolutely -must- sort out those that have less than n mem usage, try $ ps vOr | awk '{if ($8 > 15000) print $_ }'

      You just proved the point of the grandparent. To do any special filtering on your ps output, you have to parse it. Field 8 is not always going to be the same depending on the parameters I pass in to ps (if I pass nothing, ps only gives me 4 fields back; if I pass "waux", I get 11 fields back but the one I want that corresponds to the "vOr" output is now field 6 rather than 8). In Monad/MSH, as the grandparent pointed out, virtual memory size is always the property VirtualMemorySize on objects returned from get-process. More importantly, it doesn't matter whether or not VirtualMemorySize is in the actual display string. Monad pipes objects, not formatted text output. That means that while you may not see VirtualMemorySize by default when you call get-process, it's still available to you when you pipe the output, because you're piping a collection of objects containing information about the process table. Interestingly, as long as you're using cmdlets, your actions in the shell don't affect the process list. That means that if I'm grepping for something in the process list, I can be sure that I'll never find a "grep something" process to screw up my search (yes, there are ways to filter that out, but why should I have to?).

      If you're so concerned about command length, you can use the default alias 'ps' for get-process. The grandparent already used the 'where' alias for where-object. If that's not enough, you can build a very simple function or cmdlet in script that is very easy to type. In other words, if the only metric you have to measure a shell or scripting language is keystroke efficiency, you're probably not the target audience (or you're just not willing to give anything non-*nix a chance and thus have to grasp at whatever straws you can find to validate your own choices).

    36. Re:whoosh! by julesh · · Score: 2, Informative

      Let me think, Can you rotate, resize and compress a JPEG, GIF or PNG
      on the MS$ command line?


      You can if you install the appropriate tools to do so, yes. Same as with any other OS with a command line system. I have ImageMagick on my system, so yes I can.

      Can you do this ssh user@domain.com.

      Yes, if you have ssh installed.

      Can you run a firewall script from the cmd?

      Depends what you mean by "firewall script". I don't really understand what you mean, but you might mean something like "netsh firewall set opmode enable", which is the command to turn the firewall on. There are similar commands for opening/closing ports, switching notifications on and off, and so on.

      Can you chmod or chown?

      You can use those exact commands if you've installed cygwin or something similar, or if you'd rather just use the default utilities, cacls can achieve just about anything you want.

    37. Re:whoosh! by man_of_mr_e · · Score: 1

      If the unix shell were the "implementation of the Unix philosophy" you wouldn't have a monolithic shell that's capable of doing almost anything BY ITSELF.

      In other words, it wouldn't have tons of builtin functions. Why does it have them? Performance most likely. It's expensive to launch a new process for every little function.

    38. Re:whoosh! by lux55 · · Score: 1

      Wouldn't it be possible to change the Unix shells to pipe objects instead, in a somewhat backwards-compatible manner, by implementing a toString() method that would be called automatically on all types if they're treated like a string?

      So this Unix 'ps' example would still work:

      ps vOr | awk '$8 > 15000'

      But it could also be written as:

      ps vOr | awk '$_.virtualmemorysize > 15000'

      In the above, that would require cooperative changes to both the Bash and Awk languages, but the idea is theoretically possible and we wouldn't have to give up a lot of the finer aspects of the Unix shell either. Being that this change would likely require major rewrites, it's doubtful it'll ever happen, but it is possible someone will learn from Microsoft and improve Unix, and one is allowed to dream... :)

    39. Re:whoosh! by DigitlDud · · Score: 1

      When you run get-process you're getting an array of Process objects. Each containing properties about the object. PID, image name, working set size, etc. The objects also have methods, so I can easily call the Kill() method on my list of objects.

      Since this is .NET you get reflection of course. So I can pipe some arbitrary object to a command. And that command can learn what properties and methods are exposed by the object. And convert them to some different format like XML or something.

    40. Re:whoosh! by Anonymous Coward · · Score: 0

      It may be a huge improvement but only if the entire Windows application base immediately jumps on the MSH and .NET bandwagon. If history is any guide, the only applications for which MSH will be usable are, surprise, Microsoft applications. In five years, when most applications have a chance to catch up, Microsoft will release their next cycle of "innovation" on the world. Huzzah.
      There's something to be said for the UNIX tradition of simplicity, conservatism, and vendor neutrality.

    41. Re:whoosh! by Osty · · Score: 1

      In the above, that would require cooperative changes to both the Bash and Awk languages, but the idea is theoretically possible and we wouldn't have to give up a lot of the finer aspects of the Unix shell either.

      Don't forget that you'd also have to change ps. The fundamental difference is that Monad cmdlets are returning objects already, and it's the shell (of which msh.exe is simply one implementation -- implementing your own shell over the Monad core is fairly trivial) that does display (I believe objects can now tell you what their default display properties are, but this may still be a function of the shell). Going back to the ps example, there's data available to you when you run 'ps waux' that's simply not there at all when you run 'ps' or 'ps vOr'. In a Monad-like system, the 'waux' or 'vOr' parameters to ps would not affect the data output, but only the formatting (in Monad's case, you'd pipe this through a formatting cmdlet). What gets passed to awk would be the data stream, not the representation stream that gets passed to the host (the shell in this case, or whatever's consuming the Monad core).

      While the concept of passing objects can be implemented by passing serializable strings, it's a pretty fundamental change that would touch the entire system if done properly. In that light, it does make sense that the Monad project has previously given a 3-5 year timeframe to completion (I'm assuming that 3-5 year countdown started ~2 years ago).

    42. Re:whoosh! by Tim+C · · Score: 1

      A few things:

      1) the MSH shell will have command completion, so in practice you'll mostly type the first couple of letters of a command and hit tab (like you generally do with filenames now)

      2) I type fast, and prefer readablity, rememberability and maintainability of terseness any day of the week

      3) I've been using a variety of flavours of UNIX and Linux for more than 10 years now, and I can never remember the syntax of sed and awk

      4) as others have pointed out, change the parameters to ps and your second example breaks, but with get-process you're *always* filtering on the same piece of output

    43. Re:whoosh! by iserlohn · · Score: 1

      How much trouble do you think it is required to wrap the standard unix commands in something like python or ruby? Not a whole lot because most of the information will be string processing anyway.

      Beside, the standard python and ruby libraries have a ton of features to interface with the OS.

    44. Re:whoosh! by ashpool7 · · Score: 1

      That's kind of a silly fear. Currently, you have to obey a loose "object interface" when writing your own command line apps. Depending on the app, they could be the following:

      * separate each entry with \n
      * separate things within an entry with \t
      * quote strings with spaces
      * terminate each entry with a \0 if given a parameter
      * show a path to a file by delineating it with /
      * code your output in "English"

      It doesn't seem like such a bad idea. Try imagining *NIX-alikes being rewritten to adhere to such an interface. Sounds kind of nice, not having to deal with find & xargs command line hacks (sheesh, even OS X's brand new mdfind has them) to get things to talk to each other.

      A broken clock is right at least twice a day...

    45. Re:whoosh! by Anonymous Coward · · Score: 0

      SQL is based on relational algebra, not relational calculus. If you find it inflexible for that reason, PEBKAC.

    46. Re:whoosh! by julesh · · Score: 1

      $ ps vOr

      List processses, order by memory consumption, saving 52 keypresses.


      Doesn't work:

      bash-2.05$ ps v0r
      usage: ps [ -aAdeflcjLPy ] [ -o format ] [ -t termlist ]
      [ -u userlist ] [ -U userlist ] [ -G grouplist ]
      [ -p proclist ] [ -g pgrplist ] [ -s sidlist ]
      'format' is one or more of:
      user ruser group rgroup uid ruid gid rgid pid ppid pgid sid taskid
      pri opri pcpu pmem vsz rss osz nice class time etime stime
      f s c lwp nlwp psr tty addr wchan fname comm args projid project pset


      The problem is, those options to ps are not well standardised, and because there's no easy way of mapping all of the things ps can do into sensible single letter switches, every implementation there is uses them all for different things.

      However, you can bet that every implementation of monad (and I'm sure there will be one for UNIX soon) will have similar names for the fields returned by get-process.

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


      Sure, but: 'ps | where { $_.virt -gt 15000000}' is fewer still, and works just as well.

    47. Re:whoosh! by joshv · · Score: 1

      no, more like:
      man ps
      pg dn
      pg dn
      ^C
      ps vr
      Damn, not right
      man ps
      pg dn
      pg dn
      pg dn
      pg dn
      ^C
      ps vOr
      crap, what about mem usage... Well maybe awk. Where is that script I wrote last month?

      man find
      pg dn ....

    48. Re:whoosh! by julesh · · Score: 1

      Sure, but: 'ps | where { $_.virt -gt 15000000}' is fewer still, and works just as well.

      Oops, I meant 'ps | where { $_.virt[TAB] -gt 15000000}', but /. ate my tab.

    49. Re:whoosh! by Anonymous Coward · · Score: 0

      Stop pretending cygwin is the answer. Cygwin's uses are marginal at best. You have no improved access to basic windows functionality beyond what the dos shell gives you, and one could argue decidedly worse due to the need to mount parts of the windows filesystem into your cygwin file system.

      And cygwin is slow. Really horribly slow.

      The only use I've found for it is a quick file parsing job where I needd a subset of the data from some text file. It is mostly useless for system administration scripts.

    50. Re:whoosh! by Anonymous Coward · · Score: 0

      That was an O, not a 0.

    51. Re:whoosh! by Eudial · · Score: 1

      ps vOr
      not
      ps v0r

      Subtle difference, it's not a zero, it's a capital o.

      --
      GAAH! MY PRINTER IS ON FIRE!!! PUT IT OUT! PUT IT OUT!
    52. Re:whoosh! by bushidocoder · · Score: 1

      It looks alot more like sql when you start playing with the join operator - I forget the exact syntax (I haven't played with it for a year), but msh allows the equivelant of

      select ps.pid, count(*)
      from ps
      inner join netstat on ps.pid = netstat.pid
      group by ps.pid
      order by count(*) desc

    53. Re:whoosh! by Anonymous Coward · · Score: 0

      Why not using the SQL syntax then? I don't want more syntaxes, I want less. All that is crap if there is no standard behind. At least UNIX can be considered a kind of de facto standard despite all the variations (like in SQL). Monad is not a standard, wake me when it is one.

    54. Re:whoosh! by brpr · · Score: 2, Informative

      The real world. How many method invocations will your structured 10kb of data require to find the relevant data items? Think about it--there's a reason xml stream parsers are much faster than parsers which load the entire xml doc into an object model.

      You're really, really confused. Take a simple example, such as getting the process ID of a task from that task's name. The obvious way to do it in bash is to do a ps ax, then grep through the lines of output and finally use awk to separate out the process id field. With Monad, you could (probably) just make a method call like OperatingSystem.GetPID("TaskName") and get the information you wanted directly and efficiently, without any parsing overhead. If you think that the most efficient way of handling structured data is to serialize it into text streams and then parse it with primitive parsing tools, you're just plain nuts. The most efficient way to handle structured data is to actually process it as structured data, not as a text stream. Presumably, in those cases where your data actually is a text stream, Monad would allow you to process it as such. But text streams are a poor way of representing most structured data.

      --
      Freedom is not increased by mere diminuation of government. Anarchy is freedom for the strong and slavery for the weak.
    55. Re:whoosh! by Anonymous Coward · · Score: 0

      And how did you know to type $8 instead of $3 or $9? How did you know to type vOr while we're at it? It's not about number of characters; sysadmins aren't sitting in a room being paid for number of commands typed per hour; it's about readability and ease of use. With Monad, I just have to remember the names of the fields of the process object instead of "$8" and "vOr".

    56. Re:whoosh! by Osty · · Score: 1

      With Monad, I just have to remember the names of the fields of the process object instead of "$8" and "vOr".

      You don't even have to do that, since Monad objects are discoverable. Run "get-process | get-member", and you'll get the type of object that get-process returns (System.Diagnostic.Process) as well as all of the properties and methods available on that object. Don't remember if it's VirtualMemory or VirtualMemorySize? Use get-member. It's no different than using "man ps" to figure out what options you can pass to ps, but because it's exposing .NET objects you may already be familiar with the System.Diagnostic.Process type from your other code.

    57. Re:whoosh! by Anonymous Coward · · Score: 0

      Your attitude is exactly why people don't like nerds. Fuck, I'm a nerd and I don't like nerds.

    58. Re:whoosh! by Anonymous Coward · · Score: 0

      I guess you didn't get the point. A tipical example is the method to access scanners: TWAIN vs SANE. TWAIN is implemented in a dll, but there is no way to automate (well, maybe using some sort of key logger/player), the scanning process: every time you try to scan something, a window is displayed.

      With SANE you can simple run xscanimage, and you get the image on stdout.

      So, the original poster didnt say twice the same thing.

    59. Re:whoosh! by drsmithy · · Score: 1
      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.

      And I'm sure all the people running XP on their 150Mhz Pentium will be very concerned about that.

      In case you hadn't noticed, most computers for the last 5 - 10 years have had CPU cycles to burn. Personally I consider improving the user interface to be a vastly better use for them than Seti@Home.

    60. Re:whoosh! by Anonymous Coward · · Score: 0

      Let's skip the "awk" command, since it would take too many keystrokes for me to learn awk so that I'd write that.
      Excuse me? You'd have to learn Monad (and get-process and what it passes) for the same task, and awk is basically the Unix competitor to its scripting capabilities.

    61. Re:whoosh! by Stauf · · Score: 1

      [humming]Feedin' the troll, la de dee dee[/humming]

      Can you rotate, resize and compress a JPEG, GIF or PNG on the MS$ command line? Can you do this ssh user@domain.com. Can you run a firewall script from the cmd? Can you chmod or chown?

      I dunno if it's just me, but did anyone notice that none of those things have anything to do with the shell? (Well, except maybe chmod and chown - if you push it.)

      Image manipulation? Just launch ImageMagick. You can do this in Windows right now, with the correct software installed.

      SSH? Just launch SSH. You can do this in Windows right now, with the correct software installed.

      A firewall? Launch your firewall script. You can do this in Windows right now, with the correct software installed.

      Are we seeing a pattern? 100% of the relevant stuff you mentioned doesn't involve the shell, and relies on external apps. As for chmod and chown, apart from the fact that you can install them in Windows (with cygwin), they're totally irrelevant - Windows has a much more complete permissions system then your average *nix, and it has the command line tools to support it in 'cacls'.

      The day I can boot Windows to the command line and strip it down to its kernel, only implementing the services I want, I will know that MS$ has finally stolen everything from Linux. MS$ is crap, It will always be crap. Putting a dress on a pig won't make it pretty - unless your another pig!

      Sure. You whine about how you can't do certain things in Windows, things which are as easy to achieve as in your *nix, then you turn around and whine that if you could do them, Microsoft would be stealing.

      How does supply and demand work in your world?

    62. Re:whoosh! by UnapprovedThought · · Score: 1
      parsing text is one of the hardest things for a modern processor to do

      Is it harder than going to disk to load pages from a hugely bloated object-handling library? Even if it isn't bloated today, it will be, because you do not have control over the source.

      Objects are fine for complex graphical junk. For parsing process statistics and such object instances and their attendant memory handling overhead are overkill.

    63. Re:whoosh! by phiwum · · Score: 1

      Excuse me? You'd have to learn Monad (and get-process and what it passes) for the same task, and awk is basically the Unix competitor to its scripting capabilities.

      Fair enough, but I was already skipping the requirement of learning awk from my estimates.

      Let's take it for granted that our hypothetical shell-user knows the basics of both awk and Monad. In this case, I *think* that constructing the Monad command would be easier for me than constructing the command using awk (which involves knowing the flags for ps and which field is the correct output field).

      I don't think that it is a critical difference, but counting keystrokes is a little misleading. I'm also not suggesting that Monad is better simply because it uses long but easily remembered fields like virtualwhosits or whatever that easily remembered field was called. Just that the difference between the two shouldn't be measured by keystrokes on the line.

      --
      Phiwum's law: anyone that names an obvious law after himself and then puts it in his own sig is just pathetic.
    64. Re:whoosh! by IpalindromeI · · Score: 1

      What on Earth do you mean by this?

      He probably means that the objects will be serialized for piping, which means breaking the object down and rebuilding it on the other side. How else do you expect processes to pass object information to each other? I highly doubt they just pass memory addresses and call the methods directly.

      --

      --
      Promoting critical thinking since 1994.
    65. Re:whoosh! by julesh · · Score: 1

      ps vOr
      not
      ps v0r

      Subtle difference, it's not a zero, it's a capital o.


      Still doesn't work. My point stands: the command line options aren't standardised, and single character selectors don't easily map to such a complex scenario, so different implementors have chosen different approaches.

      bash-2.05$ ps vOr
      usage: ps [ -aAdeflcjLPy ] [ -o format ] [ -t termlist ]
      [ -u userlist ] [ -U userlist ] [ -G grouplist ]
      [ -p proclist ] [ -g pgrplist ] [ -s sidlist ]
      'format' is one or more of:
      user ruser group rgroup uid ruid gid rgid pid ppid pgid sid taskid
      pri opri pcpu pmem vsz rss osz nice class time etime stime
      f s c lwp nlwp psr tty addr wchan fname comm args projid project pset

  14. Re:strings for piping by Anonymous Coward · · Score: 0

    once again, shells don't use strings for piping, it's binary data!
    Ex:
    bzcat linux-2.6.8.1.tar.bz2|tar xfv -
    Is this text?
    One can, if he want to, serialize object and use pipes.

    PS : I know tar jxvf

  15. One Perl by Doc+Ruby · · Score: 3, Interesting

    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

    1. Re:One Perl by Telastyn · · Score: 3, Insightful

      Why do the majority of 'out of the box' unix scripts run in plain sh?

      Because in single user mode, or on a minimal install, that's all that guaranteed to be there.

    2. Re:One Perl by offline · · Score: 1

      I would suggest that the reason most don't is that, suddenly, all of your normal OS commands -- ls, cat, et al -- are no longer first-class commands and now require extra syntax to execute. This is not a good thing for most people.

      I've tried it myself, but was put off it by the difficulty (relative) of getting an "ls -l" to work. Which should tell you something.

      --

      C
      --
      Democracy would work just fine if people weren't so goddamned stupid.

    3. Re:One Perl by Doc+Ruby · · Score: 1

      And they all run in Perl with just

      print `script`;

      That sh guarantee ensures that an installed Perl will get the same access to it as any other programs, or programmers (or sysadmins). We're talking about sysadmins, who can run "perl -v || apt-get install perl" (or its local equivalent. The Windows equivalent is harder, but that's the point of installing a sysadmin tool like Monad - or Perl.

      --

      --
      make install -not war

    4. Re:One Perl by SparafucileMan · · Score: 1

      you coulda just written a mini interprerter to take care of the syntax for you.

    5. Re:One Perl by Anonymous Coward · · Score: 0

      I see this as a good thing because it allows the user to alias commands for a more refined output. In your example, most shells will allow you to alias ls to '/bin/ls -l' to override the default behavior of the ls command.

    6. Re:One Perl by offline · · Score: 1

      Which is my point, better made than I could have hoped.

      --

      C
      --
      Democracy would work just fine if people weren't so goddamned stupid.

    7. Re:One Perl by kckman · · Score: 1

      this can never be, they don't own perl. it's in the license.. they can not assimilate perl. The BORG will fail

    8. Re:One Perl by Doc+Ruby · · Score: 2, Interesting

      Microsoft ("they?") doesn't own Perl - and they don't have to. I can install Perl on a Windows machine without Microsoft having anything to do with it. The idea that a sysadmin tool has to be owned by the owner of the OS is crazy, but certainly consistent with the "Papa Microsoft" monopoly mindset.

      In fact, I wonder why we don't see more "Windows Distros". Bundles of Windows with preconfigured app/content packages. We see some insignificant bundles by computer retailers, like Dell, which include other apps with Windows. But those bundles are to sell computers. How come I don't see Windows upgrade licenses bundled with, say, an OpenOffice.org package, preconfigured to work right? Is there something in the Windows reseller license which requires that only Microsoft can bundle? Or just something in the Windows marketing agenda that prevents them from allowing those kinds of deals? Or merely apathy, and the monopoly mindset that prevents entrepreneurs from reselling Windows OS products bundled with non-MS apps?

      --

      --
      make install -not war

    9. Re:One Perl by eyeye · · Score: 1

      I would suggest that the reason most don't is that, suddenly, all of your normal OS commands -- ls, cat, et al -- are no longer first-class commands and now require extra syntax to execute. This is not a good thing for most people.

      http://search.cpan.org/~nwclark/perl-5.8.7/lib/She ll.pm
      "Shell - run shell commands transparently within perl"

      I've tried it myself, but was put off it by the difficulty (relative) of getting an "ls -l" to work. Which should tell you something.

      Yes it tells me you are a moron if `ls -l` puts you off. Or if you use the above module the syntax is ls('-l')
      --
      Bush and Blair ate my sig!
    10. Re:One Perl by colinrichardday · · Score: 1

      But what if that "moron" needs to run it in a production program? The link specifically states that one should not run Shell.pm in a production program. Also, quoting does not yet work.

    11. Re:One Perl by SA+Stevens · · Score: 1

      We're talking about sysadmins, who can run "perl -v || apt-get install perl"

      In single user mode when only the root partition is mounted? You have a rather limited grasp of the value of simple-small-powerful shells.

    12. Re:One Perl by Anonymous Coward · · Score: 0

      What the hell does "Also, quoting does not yet work." mean?

      As for Shell.pm, well, it's irrelevant. How hard is typing: `ls -l` again? Not very? Right. Not to mention perl usually has built in ways to do these sort of things that are far superiour.

    13. Re:One Perl by colinrichardday · · Score: 1

      Well, then, why the link mention them?

      But some sheel commands do require quoting.

    14. Re:One Perl by Doc+Ruby · · Score: 1

      No, I'm comparing Monad to Perl. I haven't said sh is bad - to the contrary, I've said how useful it is to wrap sh in Perl. Of course when Perl isn't appropriate you're stuck with sh. In fact, when you embed Linux in, say, a doorknob, you might be stuck with telnetd.

      --

      --
      make install -not war

    15. Re:One Perl by Doc+Ruby · · Score: 1

      What's so hard about "print `ls -l`"? Of course, if you don't know Perl, it's too hard. By the same token, if you don't know shell script, like "ls -l", it's all too hard: use the Windows Explorer, and let a sysadmin do the work.

      --

      --
      make install -not war

  16. One benefit to Monad. by Deal-a-Neil · · Score: 3, Funny

    .. it won't be so startling when you get the blue screen of death, seeing that you're already in a text screen mode.

    1. Re:One benefit to Monad. by VistaBoy · · Score: 1

      I'd think it would be worse, since instead of your body having time to recover from the startle while the monitor is changing resolutions, a text-mode to text-mode BSOD is instantaneous.

      Of course, I've never personally had much trouble with BSODs since Windows XP came out, but that's another story.

    2. Re:One benefit to Monad. by LetterJ · · Score: 1

      Easy joke (though pretty worn thin at this point), but it's a lot like the criticisms leveled at Linux that are 2-3 years stale. It hasn't been a particularly relevent criticism for quite a while.

      I have 4 Windows machines running at home (along with a couple of Linux boxes) and an XP Pro system at client site where I am working currently and I haven't seen a blue screen in 3 years on any of them.

    3. Re:One benefit to Monad. by Anonymous Coward · · Score: 0

      Really, isn't it about time you booted at least one of them up?

  17. Re:That's all well and good by msuzio · · Score: 1

    Actually, I think something like Applescript for Windows would be awesome. It's a very Unix-like way to get apps to work together, it could make Windows a lot more flexible for many people's needs.

  18. Anything would better! by toupsie · · Score: 3, Insightful

    Trying to script using cmd, vbscript, wsh, wmi, adsi technologies compared to the userland in Unix systems for core system administration is a complete hassle. I have ended using Perl w/ Win32::* extensions and a lot of backticking and substitutions to get the job done. I will be looking forward to any improvements that Monad provides. I really hope that Microsoft looks toward BSD (Mac OS X) and Linux systems and takes to heart the ease that shell scripting in these systems provides. And for God's sake, make it easier to determine the IP address associated to a printer in a clustered virtual print queue! (Hint: you have to use an undocumented DLL that can only be found in a locked filing cabinet stuck in a disused lavatory in an unlit cellar with a sign on the door saying 'beware of the leopard' section of the Resource Kit).

    --
    Strange women lying in ponds distributing swords is no basis for a system of government.
    1. Re:Anything would better! by bob@dB.org · · Score: 1
      you have to use an undocumented DLL that can only be found in a locked filing cabinet stuck in a disused lavatory in an unlit cellar with a sign on the door saying 'beware of the leopard'...
      That's the display department!
      --
      Acts@core.mailboks.com Acrux@core.mailboks.com Adam@core.mailboks.com Adar@core.mailboks.com Ada@core.mailboks.com
    2. Re:Anything would better! by Anonymous Coward · · Score: 0

      you dont have to write script in vbscript you can use ecmascript (with ms's extensions) which is also known as javascript and if thats good enough for Mozilla and the whole web it should be good enough for Windows use

      but no lets keep re-inventing the wheel, over and over

    3. Re:Anything would better! by Anonymous Coward · · Score: 0

      > but no lets keep re-inventing the wheel, over and over

      Funny you say that after suggesting doing the damn thing, no?

    4. Re:Anything would better! by Anonymous Coward · · Score: 0

      Uh?

      I can't even imagine something simpler than vbscript/wsh/wmi/adsi. I use it everyday and I find it ridiculously simple. I honestly don't know what you find complicated there. And no, don't even try saying *nix shells are easier, that's just completely laughable.

  19. Uh...dupe? by Anonymous Coward · · Score: 0

    I'm pretty sure about this one...

  20. What I'm wondering... by trezor · · Score: 1

    Does this new shell have a 'ln -s' command? I guess not, since no reports (I've heard) of the filesystem have mentioned symlinks.

    Did I mention how much I hate not having symlinks in Windows? A new usuable shell is all dandy, but I'd like symlinks as well.

    --
    Not Buzzword 2.0 compliant. Please speak english.
    1. Re:What I'm wondering... by SavvyPlayer · · Score: 1

      NTFS does support linking via the concept of filesystem 'junction points':

      http://support.microsoft.com/default.aspx?scid=kb; EN-US;q205524

      Granted, this is nowhere near as elegant as ln -s.

    2. Re:What I'm wondering... by Anonymous Coward · · Score: 0

      Use cygwin or msys. You get fully functional symlinks, hard links, fifos, domain sockets and some device nodes too :)

      Some things require NTFS, but most stuff works even on Win98.

    3. Re:What I'm wondering... by Utopia · · Score: 2, Informative

      Windows has had symbolic links since Windows 2000. It was called junction points.

      In XP it was renamed as reparse points.




    4. Re:What I'm wondering... by Tony+Hoyle · · Score: 1

      reparse points are actually hard links not symlinks (and the default win32 implementation only allows them on directories).

      cygwin does a reasonable symlink implementation, but it's not available to the wider OS. It *should* be possible, using an IFS filter driver, but nobody's written one.

    5. Re:What I'm wondering... by shutdown+-p+now · · Score: 1

      Only those aren't symlinks, they are hard links. Try e.g. linking a directory from another partitio that way.

  21. Or you could just download the release-quality one by mcc · · Score: 4, Funny
  22. Wasn't it already in the beta? by bersl2 · · Score: 1

    We've had two recent articles on it, and I know there was at least a third in the distant past.

    And with as verbose as it is, you might as well use a compiled program, or go with Perl or Python.

    1. Re: Wasn't it already in the beta? by mkithara · · Score: 1

      That was only a pre-beta preview. The Beta 1 drop on June 17th is much more complete and usable. It's still missing a number of features (e.g. sort-object ascending only), but they are making progress and it's a huge improvement over cmd.

    2. Re: Wasn't it already in the beta? by Barlo_Mung_42 · · Score: 1

      If it's missing features shouldn't it still be in alpha stage? Beta is supposed to mean that it's feature complete and being tested.

    3. Re: Wasn't it already in the beta? by Suddenly_Dead · · Score: 1

      That's typically used, but "beta" can also mean something that's meant for testing by the greater public. There are no real guidelines for development stage names :)

  23. Wrong by Anonymous Coward · · Score: 0

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

    See the sad state of the Linux Desktop.

    1. Re:Wrong by ettlz · · Score: 1

      Those who do not understand MacOS are condemned... no, hang on, those who do not understand Xerox Alto are condemned..., etc.

  24. I find it ironic by v1 · · Score: 2, Funny

    how MS bashes linux, and yet is trying to become more and more like it...

    Probably a very common business tactic, bash the competition and at the same time assimilate its best features, but still, poor style.

    --
    I work for the Department of Redundancy Department.
    1. Re:I find it ironic by Saeed+al-Sahaf · · Score: 1
      how MS bashes linux, and yet is trying to become more and more like it...

      It's a command line shell. Does *nix have an exclusive right on those? And, it's not much like *nix shells, except that it's command line... You talk an awful lot about "bashing", pal. Perhaps it is you?

      --
      "Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
    2. Re:I find it ironic by vcv · · Score: 1

      Try turning that around. Linux people bash Windows even moreso, yet have strived to become more like it. Please.. get over yourself. This is not for the average windows user at all. It's for sysadmins and geeks. It will become much more integrated to windows than bash or perl or anything, which will give it it's power.

    3. Re:I find it ironic by daniil · · Score: 1
      Probably a very common business tactic, bash the competition and at the same time assimilate its best features, but still, poor style.

      Just like the Open Source community bashes Microsoft, yet is, at the same time, assimilating features of Windows and other Microsoft products?

      --
      Man is a slave because freedom is difficult, whereas slavery is easy.
    4. Re:I find it ironic by Anonymous Coward · · Score: 0

      Could be worse - they might be trying to tcsh the competition.

    5. Re:I find it ironic by Saeed+al-Sahaf · · Score: 1

      ...cough***OpenOffice***cough...

      --
      "Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
    6. Re:I find it ironic by reflective+recursion · · Score: 1

      yeah.. we all know KDE and GNOME are completely original. get back in your cave, troll.

      --
      Dijkstra Considered Dead
    7. Re:I find it ironic by Guppy06 · · Score: 1

      Kinda like how Linux zealots here on Slashdot bash Windows yet try to make distros more like it.

      The sword cuts both ways.

    8. Re:I find it ironic by NineNine · · Score: 1

      I agree. The few times I've gotten various flavors of Linux to work, they all looked almost *exactly* like Windows. The only real difference was that the button in the bottm left hand corner didn't say "Start". So I agree, Linux companies are doing the same thing... bashing, but desperately trying to emulate.

    9. Re:I find it ironic by WindBourne · · Score: 1

      From what I have read, the only real difference is that it is intended to filter data via pipes using XML. Just about all other aspects are nothing but a *nix shell.

      --
      I prefer the "u" in honour as it seems to be missing these days.
    10. Re:I find it ironic by thebagel · · Score: 1

      Not bash, stupid, Monad. Jeez... :)

    11. Re:I find it ironic by Anonymous Coward · · Score: 0

      cough*** dumpster diver worshiper*** cough *** assstroturfer***

    12. Re:I find it ironic by ocelotbob · · Score: 1

      Funny, the most functional Linux desktop setup for me looks nothing like windows at all. Yes, they start out looking like windows for sake of familiarity, but are quickly adaptable in ways windows is incapable of without a raft of 3rd party cpu hogging extensions and replacements.

      --

      Marxism is the opiate of dumbasses

    13. Re:I find it ironic by Anonymous Coward · · Score: 0

      way to miss the fucking point, dipshit. there is no physical law that says 3rd party extensions have to be cpu hogging, either. your zealotry really is annoying, cunt rag. and in case you haven't taken your head out of your enlarged anus, *all* Linux software is 3rd party. so stfu, sit the fuck down, and realize linux isn't the end-all be-all of software. it's nothing but a fucking clone of a has-been system that wasn't even that good to begin with. yes, that is fucking right. unix is *shit* compared to something like genera (and many others).

  25. Re:That's all well and good by Kafteinn · · Score: 2, Interesting
    The question is, who would really be interested in it at all?
    The more power to the user the more power to botnet controllers!

    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.
  26. Re:That's all well and good by diegocgteleline.es · · Score: 2, Insightful

    People who uses windows, obviously. Most of Microsoft users do not analize what they use - they just use it, and they've though that buttons are better than scripting just because Microsoft has been telling them that for years. Now that microsoft says scripting is useful, they'll think it's useful. They don't know if scripting is "good" or "bad", they're not CS people (and even if they are they may be clueless) so they think whatever they're told to think

  27. That explains Midcrosoft, eh? by Anonymous Coward · · Score: 0
    Those who do not understand Windows are condemned to reinvent it, poorly.

    Well, now. That explains every damn thing Microsoft has done the past two decades or so, now doesn't it?

    1. Re:That explains Midcrosoft, eh? by Anonymous Coward · · Score: 0

      Way to come off like a pissant. Next time, try "I know you are but what am I?".

    2. Re:That explains Midcrosoft, eh? by Anonymous Coward · · Score: 0

      Way to come off like a pissant.

      Uh...I know you are but what am I? Better?

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

  29. Re:That's all well and good by Kamiza+Ikioi · · Score: 1

    Windows network admins?

    How about Windows users? Some of us work non-IT specific jobs that still heavily involve computers. Whether the IT department supports it or the company, Windows is often the only option for power users without IT priviledges to run something like CYGWIN while at work. If Monad scripting is half as powerful as even Slashdot readers think, it would be a great improvement over current Windows working conditions.

    As for home... /me shrugs, got bash and perl for scripting.

    --
    I8-D
  30. Re:Or you could just download the release-quality by nberardi · · Score: 1, Troll

    Not really based off the same ideas and comcepts. You should really try reading the wiki to better understand what Monad is about. Instead of building scrips through Perl or Python or whatever you use this is going to be centered around building "scripts" in .NET. I would encourage you to look more into this before you start opening your big mouth and downplaying something you know nothing about.

  31. Re:strings for piping by DrSkwid · · Score: 1

    that's gnu/tar buddy =)

    --
    There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
  32. Re:That's all well and good by NutscrapeSucks · · Score: 1

    Windows Script Host (often with VBScript) is "something like AppleScript". Almost exactly alike.

    Personally I don't think that either WSH or AppleScript are very Unix-like -- both rely on higher-level IPC and complex datatypes, not text and pipes.

    It seems like Monad is trying to be a halfway point between a Unix-like shell and a scripting language. This might have something to do with the programming ability (or lack thereof) of those who admin Windows systems.

    --
    Whenever I hear the word 'Innovation', I reach for my pistol.
  33. It got modded up because by Anonymous Coward · · Score: 0

    Because the ability to use a CLI demonstrates a true understanding of what's happening on the computer.

    And remember Unix came about because of the failures of Multics - an operating system that tried to be everything to everybody. Sound familiar?

    1. Re:It got modded up because by NickFitz · · Score: 0

      Because the ability to use a CLI demonstrates a true understanding of what's happening on the computer.

      No, using the switches on the front to input the bootstrap code in binary demonstrates a true understanding of what's happening on the computer.

      Or, put another way: my clumsy and awkward user interface is geekier than yours :-)

      --
      Using HTML in email is like putting sound effects on your phone calls. Just say <strong>no</strong>.
  34. Another screen shot by Skiron · · Score: 0, Troll

    Here's another Screenshot: Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\> cd /mnt/dvd C:\> ERROR. You do not have the rights to that as I see you haven't paid $750.00 or even got an ID card. C:\> Please run 'communist reporting tool' to fix this forever.

    1. Re:Another screen shot by Anonymous Coward · · Score: 0

      Yourjokesucked.Trytoformatit,first.

  35. Re:Or you could just download the release-quality by mcc · · Score: 1

    Instead of building scrips through Perl or Python or whatever you use this is going to be centered around building "scripts" in .NET.

    Aha.

    "Scripts".

    Well this changes everything.

    I've read up on monad, thanks.

  36. backslashes by hey · · Score: 2, Insightful

    While they are on their way to being more Unix-like how about fixes their broken backslashes. It would be nice to be able to do:

    cd '/Program Files/Mozilla Firefox'

    1. Re:backslashes by Tony+Hoyle · · Score: 2, Informative

      That's just a cmd.exe (and explorer.exe) limitation.

      The NT kernel fixed the backslash brokenness years ago.

    2. Re:backslashes by ettlz · · Score: 1

      And while we're on it, how about the draconian file-locking schemes, and a path-driven filesystem that won't let you rename directories higher up in the hierarchy of an open file?

    3. Re:backslashes by TheAncientHacker · · Score: 3, Insightful

      And yet another classic example of tunnel vision Unix bigotry. If it isn't exactly the way I learned it, it's broken.

      Here's a clue, try learning something new once in a while...

    4. Re:backslashes by Anonymous Coward · · Score: 0

      Forward slashes tend to be easier to type.

    5. Re:backslashes by slavemowgli · · Score: 2, Interesting

      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.
    6. Re:backslashes by Anonymous Coward · · Score: 1, Informative

      The first DOS versions didn't support directories at all-- all files were flat on the disk, so you didn't need path separators. By the time a path separator was needed, front slashes were already being used for command line parameters, so they needed something else, and they picked the "next best" thing-- the backslash.

      Now, as to why they decided to use front slashes for command line parameters, I have no idea.

    7. Re:backslashes by m50d · · Score: 3, Informative

      Yes, there is a reason for it. The original MS-DOS didn't have directories and used / for command-line switches where unix uses - (e.g. copy /b or dir /p). When MS-DOS 2 came out with directory support, they wanted to stay compatible (so you could use batch files from DOS 1, etc.) but with the primitive state of the applications back then, using / as both the command switch thing and directory separator would confuse them, so MS decided to use \ as the directory separator instead.

      --
      I am trolling
    8. Re:backslashes by Guy+Harris · · Score: 1
      Now, as to why they decided to use front slashes for command line parameters, I have no idea.

      I think CP/M did so, and QDOS was imitating CP/M.

      As for CP/M, they probably chose / because various OSes from DEC did so.

    9. Re:backslashes by spitzak · · Score: 1

      Here's a clue: backslashes are used to quote the next character in virtually every programming language, including ones supported directly by Microsoft.

      And the Win32 API supports *BOTH* forward and backward slashes. Why is that? Perhaps because they are smarter than you are and realized that it was a very well-established standard.

      Now periods would be better, but when Unix was designed they were already too entrenched as the "extension seperator".

    10. Re:backslashes by julesh · · Score: 1

      That's just a cmd.exe (and explorer.exe) limitation.

      The NT kernel fixed the backslash brokenness years ago.


      Actually, both DOS and Windows have always allowed forward slash directory separators. Older versions of DOS even (apparently) had a config option that could change the command line option delimiter to '-' for system commands, so that you could use forward slashes in the arguments to them.

      DOS started out its life as a version of CP/M for people with a UNIX background.

    11. Re:backslashes by eugene_roux · · Score: 1
      so MS decided to use \ as the directory separator instead

      ... In their all but... erm... infinite wisdom opting for the freaking escape character!

      Not something at all unknown to them, as most of the support utilities for DOS 2 was programmed in C.

      Bottom line: it was either malice or gross stupidity on their part.

      You pick...

      --
      Part Time Philosopher, Oft Times Romantic, Full Time Unix Geek
    12. Re:backslashes by johnw · · Score: 1

      Never mind the NT kernel - normal slashes as directory separators have *always* worked in MS systems - right the way back to MS-DOS.

      It was always just a cludge in COMMAND.COM/CMD.EXE which prevented their use.

      John

    13. Re:backslashes by Anonymous Coward · · Score: 0

      Monad does this by default. You can use forward or backward slashes interchangably.

    14. Re:backslashes by AeroIllini · · Score: 1

      When MS-DOS 2 came out with directory support, they wanted to stay compatible (so you could use batch files from DOS 1, etc.) but with the primitive state of the applications back then, using / as both the command switch thing and directory separator would confuse them, so MS decided to use \ as the directory separator instead.

      I think you have your history a little mixed up.

      From Wikipedia:

      "Fearing copyright infringement complaints from AT&T, Microsoft decided to use backslashes as pathname separators rather than normal forward-slashes."

      --
      For security, the MD5 hash of this message and sig is 09f911029d74e35bd84156c5635688c0.
    15. Re:backslashes by HishamMuhammad · · Score: 1

      Now, as to why they decided to use front slashes for command line parameters, I have no idea.

      IIRC, Forward slashes for options comes from VMS. And so do the .COM and .BAT file extensions.

    16. Re:backslashes by hey · · Score: 1

      Perhaps that really is the reason. But if they really wanted to they could -even now- switch to a forward slash. They could make their commands understand dashes for options and when you see
      copy /b c:/file1.txt c:/file2.txt is pretty reason for a program to understand that the /b is an option.

    17. Re:backslashes by m50d · · Score: 1

      I was just going by what I'd read in the jargon file.

      --
      I am trolling
    18. Re:backslashes by m50d · · Score: 1

      But then /b could legitimately mean you wanted to copy the file b in the current directory.

      --
      I am trolling
    19. Re:backslashes by fgb · · Score: 1

      Why, yes, there is a reason and, believe it or not, Microsoft was not completely to blame.

      When Microsoft was about to release MSDOS 2, the first version of DOS to support hierarchical directories, they actually tried to do the right thing and use slashes for a separator and dashes for options.

      IBM did not like that. They wanted, for whatever reason, their new OS to not feel like Unix. So they asked Microsoft to deliberately make it different.

      At the time Microsoft was a fairly small company and was easily pressured by IBM to do things the way they wanted.

    20. Re:backslashes by fnj · · Score: 1

      /b would be the file in the ROOT directory of the current volume, not the CURRENT directory. ./b (or just b) is the file b in the current directory.

    21. Re:backslashes by fnj · · Score: 1

      "Fearing copyright infringement complaints from AT&T, Microsoft decided to use backslashes as pathname separators rather than normal forward-slashes."

      Oh come now; no one but whoever wrote that nonsense believe it.

    22. Re:backslashes by Anonymous Coward · · Score: 0

      fyi

      it works fine

      F:\>msh
      Microsoft Command Shell
      Copyright (C) 2005 Microsoft Corporation. All rights reserved.

      MSH> cd '/Program Files/Adobe'
      MSH> get-location | format-list

      Drive : F
      Provider : System.Management.Automation.ProviderInfo
      Provide rPath : F:\Program Files\Adobe
      Path : F:\Program Files\Adobe

      MSH>

    23. Re:backslashes by Matilda+the+Hun · · Score: 1

      Alright, so by your arguement, if Windows starting shipping in Spanish, we shouldn't complain about it not being in English and just learn Spanish instead.

      Absolutely brilliant. Everyone should just stop complaining about what they don't like about something, because obviously the developers of Monad know what we want in a shell better than us mere mortals do.

      --
      Tluin natha Linux xxizzuss uriu olt bwael mon'tun.
    24. Re:backslashes by Anonymous Coward · · Score: 0

      yeah, that's why the backslash is the small little key and the forward is the larger key on just about 99% of PC keyboards.

    25. Re:backslashes by Anonymous Coward · · Score: 0

      Well, I can think of a bunch of characters that would be better than /, \, or even period.

      Apple's choice of : for one, although there are probably a bunch of characters even less likely to be used for conflicting things.

    26. Re:backslashes by TheAncientHacker · · Score: 1

      Here's a clue: backslashes are used to quote the next character in virtually every programming language, including ones supported directly by Microsoft. Here's a clue: backslashes are used to quote the next character in virtually every programming language derived from C which was meant for Unix. Again, the world didn't begin and end with Bell Labs in the late '60s.

    27. Re:backslashes by Deraj+DeZine · · Score: 1

      I dislike using backslashes because the backslash key is in different positions and geometries on nearly every keyboard I've used. It's like every keyboard designer forgot about that particular key and then had to fit it in somewhere that wouldn't look hideous.

      Not a big deal, but I prefer forward slashes (which apparently work in MSH anyway).

      --
      True story.
    28. Re:backslashes by Stauf · · Score: 1

      And yet another classic example of tunnel vision Unix bigotry. If it isn't exactly the way I learned it, it's broken.

      Backslashes are, and have always been a bad idea. They were implemented as a hack so that old DOS users, from before there was any sort of file structure, could still use the command line switches (like 'dir /p') they were used to.

      The reason backslashes aren't as good as forward slashes is simple - the backslash is (and at the time, was) the universally accepted escape character. DOS programmers had to deal with paths full of '\\'s, software for any other OS had to be rewritten with '\\' where before there was only '/'. This caused hell with assembly programmers where every byte was then nudged up a character. Eventually, most programming languages introduced headers and libraries that translated the '/' into a '\\' - but it was truly an ugly hack just so that the interface wouldn't change all that much.

      Of course, in the lag time in between it being introduced and libraries arriving that hacked around the problem - people scambled for a decent escape character. They couldn't use '\', they couldn't use '/', in fact, they couldn't use any typeable key on the keyboard. Ever used ANSI.SYS? It used the actual 'Esc' keycode - ASCII 27 - as it's escape character. I remember using some app that used the tilde, and having all sorts of trouble interacting with a unix host.

      Of course, all the trouble couldv'e been avoided if MS had used the then currently accepted standard of the '/' as the path delimiter. Sometimes the all the "tunnel vision Unix bigotry" is actually just common sense.

    29. Re:backslashes by Heroic+Salmon · · Score: 1


      Windows and Unix are not the only two operating systems. Windows is in fact, based more on VMS than Unix.

      Be happy that your directories don't look like this in Windows: disk1:[programfiles.mozillafirefox]

    30. Re:backslashes by spitzak · · Score: 1

      Backslashes were used in Algol and many Algol-derived languages.

    31. Re:backslashes by spitzak · · Score: 1

      I think period really makes sense as it matches the syntax used by virtually all programming languages to indicate a sub-portion of a file.

      The problem is that period makes so much sense that it had already been used to tack on a file extension in flat file systems. Before file extensions were used to identify type, they were used to seperate parts of files. For instance foo.pas, foo.obj and foo.com were used on RSX-11M derived operating systems to identify the Pascal source code, the compiled object code, and the executable version of the program "foo". This made period the obvious selection.

      Unfortunately the need to be compatable with that forced Multics/Unix to select a different character (otherwise typical uses of foo.bar would have produced a whole lot of subdirectories, which at the time were very inefficient compared to a file).

      You are right that after period, colon is the best choice. Colon was already used by RSX-11M for device selection (much like the CPM and MSDOS disk selector, and url interface selector). It does seem obvious to reuse it for directories, especially as Unix (and I think Multics) intended always to hide the devices as mount points. My best guess is that they wanted to use an unshifted character.

      Slash has an obvious problem that it conflicts with how dates are written. But it is possible at the time that the idea that you would use punctuation in filenames was considered unimportant.

      I think the next development would be to eliminate the reservation of *any* character in filenames, allowing them to be identified with a sequence of bytes. This will include allowing 0 and slashes in filenames, and also means that all interpretations (such as "case independence") are removed. Of course there will be some syntax and quoting done so users can type filenames, but this will be interpreted and removed by user-level code before the system is passed the filenames. By putting it at the user level, you can try different seperator characters. I think Plan9 has some of this, though they still reserve the null character.

  37. Re:GNU/tar by Anonymous Coward · · Score: 0

    don't worry buddy, i know what's posix and what are gnu extensions. =)

  38. The GPL is viral! by tehshen · · Score: 1

    This is just more proof that the GPL is a viral licence! Microsoft just had to look at open-source software, and all the features suddenly spread to the Microsoft products! :)

    --
    Guy asked me for a quarter for a cup of coffee. So I bit him.
  39. Monad?!?! by 3vi1 · · Score: 3, Funny

    "What should we name it?"

    "Let's combine 'Microsoft' and 'Gonad'. It'll make Unix jealous."

    1. Re:Monad?!?! by Anonymous Coward · · Score: 0

      Wouldn't that be Micronad?

    2. Re:Monad?!?! by glib909 · · Score: 1

      Naw, Gonad will be the GNU free implementation.

      And yes, I'd searched for 'Gonad' as soon as the comments page loaded ;)
      --
      Suudsu, that stuff is G-E-W-D.
    3. Re:Monad?!?! by Shawndeisi · · Score: 1

      Could be worse. It could be named "MicroNad" :)

  40. shell bias by SparafucileMan · · Score: 2, Insightful

    fellows, does it really matter? i hear Monad is quite good. but then so is bash. so is emacs shell. or perl/python/lisp interpreter of the day...

    honestly, the shell is just another language, the utility and efficiency of which depends on the environment, the use, the user, and a million other things.

    so stop bashing Monad as a unix wannabe. unix didn't invent the commandline anyway. this is like a blind man making fun of a deaf man.

  41. Re:That's all well and good by Saeed+al-Sahaf · · Score: 1

    A CLI might be usfull to non-admin type "power" users, but almost certainly is going to be a server / network admin tool.

    --
    "Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
  42. 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
    1. Re:They tried this before by NutscrapeSucks · · Score: 1, Flamebait

      That this story has entered the Unix meme is pretty pathetic.

      Oh yeah, David Korn pwnd some MS marketing dweeb over some non-MS product! It was Unix's one shining moment in a time they were getting totally steamrolled by Windows. Way to take it to the man, Dr. Bell Labs Scientist!

      On topic, I haven't played with Monad, but it seems like MS has finally figured out you can't just put ksh on Windows and say, "There's your shell, you hippies!" -- you need to have something that actually works with the system.

      --
      Whenever I hear the word 'Innovation', I reach for my pistol.
    2. Re:They tried this before by TheAncientHacker · · Score: 1

      And again, the Unix bigot's tunnel vision...

      "So, what's a body to do when Microsoft reality collides with everyone elses?"

      Here's your turn for a clue, "Everyone else" =/= Unix advocates.

    3. Re:They tried this before by grouse · · Score: 2, Informative

      The link says the story might be apocryphal, but David Korn confirmed it right here on /.

  43. Where...? by julesh · · Score: 1

    This is all very interesting, but where do I get a copy? The blog that the poster linked to is seriously slashdotted.

    1. Re:Where...? by julesh · · Score: 1

      OK, managed to get in. But it says this:

      You the need to enter your details and you should get beta details back within a couple of days with site access to the MSH bits.

      Fuck that. Anyone got a .torrent?

  44. fsutil hardlink create by mkithara · · Score: 1

    Easy enough to hardlink files. I do wish there were real symlinks, rather than 'shortcuts', though.

  45. Groovy by Anonymous Coward · · Score: 2, Informative

    Some bits about the shell:

    Natively, both forwardslash and backslash are allowable as separators. You can use both and even intermix them. So 'C:/program files/Mozilla/' should work just fine.

    The verbosity is a bit annoying, but that can be taken care of via aliasing. Also, all options are shortenable as long as they're disambiguous. Furthermore, you can alias everything just like you can in unix, so if you don't like get-process as a name you can just alias it to gp or ps or whatever you like.

    Why it's better than using Perl: because it has built-in OS hooks. You don't get the list of processes back when you run get-process: you get a streamed list of processInfo objects. If you want to store them and use them later, you can. If you want to kill a specific process, you can run process.kill on it. Want to browse the registry or AD the same way that you browse the filesystem? You can do that too. Want to format anything in a certain way? You can pick and choose what columns to display and how to display them easily, and you can set these as the defaults for these objects.

    I'd strongly recommend trying it. As a linux user and a windows user, it has a lot to recommend it. It has much of the good parts of unix-style ideals - small parts, working together and all that is where the name comes from (it's a Leibniz idea, in case you were wondering). It's very composable and mixable. It works quite a bit better than any other scripting language in exposing the native APIs. It almost allows lamdba closures; it is a lot closer to lisp than to perl or bash.

    Try it.

    1. Re:Groovy by argent · · Score: 1

      Natively, both forwardslash and backslash are allowable as separators.

      That was true in the MS-DOS 2.11 shell. Microsoft took that out of the shell about the time they dumped Xenix.

      It looks quite interesting, but what I want to know is how this new shell interface works with applications running under Windows. One reason that the UNIX shell is so powerful is that the interface between the shell and applications is so tight. An application doesn't get passed a command line from the shell, for example, it gets passes a pre-parsed list of strings, with all variable substitution, filename expansion, and quoting already performed. This means that you can call a UNIX application from another one (a web browser, say) with the same pre-tokenized list confident that the application won't proceed to re-parse it and open some file other than the one you expected it to (or, worse, pass part of the command line back to the shell and let a bad guy into your computer).

      This is not to say that all UNIX programs are careful to call applications this way, but this is what the native API does... unless the program explicitly calls the shell to parse a command line, it doesn't get reparsed.

      Currently, Windows applications don't have this option. With Monad, what happens? Is this going to be another environment with new applications having to be written to fully take advantage of it, or will Microsoft "Monadize" existing applications to operate on the objects that Monad makes available, or does Monad "marshall" a string of monads into a conventional command line when calling external applications?

      That is, is this just a new scripting language, or is there going to be a deep change to the Windows API that really integrates existing and new applications into it? Because without that, it can't ever become for Windows what the shell is for UNIX.

      If Microsoft's making deep changes to the Windows API, I have a few suggestions. The first is, they ought to comple their port of BSD TCP/IP and make sockets and file handles equivalent.

    2. Re:Groovy by Anonymous Coward · · Score: 0

      It works just fine. If you want to pass to an executable, it'll check whether the executable/command/whatever is a native command or a monad command, and do the right thing. For native commands I'm fairly certain it is broken up into arg lists like you'd expect it to be; that is certainly the behavior you get when using it.

      This doesn't require deep changes to the Windows API; it uses the .NET and Win32 APIs that exist. The interesting thing about it is that it provides a framework to build on such that if you use it, you get all the features in Monad automatically. You can create your own cmdlets that will produce actual objects, and they'll 'just work' with the existing cmdlets. In that respect, they do add a new windows API.

      For the rest of the world to integrate correctly with these they require nothing new, but it will work better if cmdlets and cmdlet providers are written for those applications. Last I heard, most server groups at MS were doing some work to monadize their programs and offer a monad way to interact with them. I'm fairly certain that's what the Exchange group is doing too.

      In any event you don't need to monadize things, though if you do you get to leverage the object nature of Monad and get a lot of the built-in functionality for free. If you don't want to do that then you don't need to; monad parses strings just fine.

    3. Re:Groovy by argent · · Score: 1

      For native commands I'm fairly certain it is broken up into arg lists like you'd expect it to be;

      Native commands don't accept an arg list, they accept a string and break it down to an arg list themselves. That's why there's all these different syntaxes in Windows commands.

      Which is where you DO need deep changes in the API, because unless native commands participate in the Monad world, it'll just be another "bash.exe".

      Which would be a pity.

    4. Re:Groovy by Anonymous Coward · · Score: 0

      The verbosity is a bit annoying, but that can be taken care of via aliasing. Also, all options are shortenable as long as they're disambiguous

      I bet there will still be people who don't know what the hell you're talking about.

  46. Please try Monad out by jsnover · · Score: 0, Troll

    I encourage you all to download the beta and let us know how we are doing, what we got wrong and where we can do better. I really would appreciate the feedback from this community as *NIX has done a wonderful job in this area from the beginning. (Though to be fair, VMS DCL and AD400 CL did good jobs as well). The command line shell is clearly an area that we (MSFT) have opportunities to improve.

    1. Re:Please try Monad out by Anonymous Coward · · Score: 0

      Support Win2K Pro with it, and I will.

      I don't run tetherware (XP and later OSes from Microsoft).

    2. Re:Please try Monad out by wasabii · · Score: 1

      It's neat. The idea is neat.

      However it does clearly miss the point of the Unix shell. Monad needs commands written for it to do everything. The Unix shell's entire point was to build upon the existing commands and provide a way to chain them together. This lets you say "if somebody provided a program, we can script with it". This includes all programs that are not GUI on a Unix distribution. Everything.

      Monad however has to have everything written for it. You can't take your existing command line apps, or GUI apps, and intermix them to create new programs or script with what you have. This means right out of the gate, Monad is going to be pretty useless to a real administrator.

      It has potential to eventually give you a scriptable interface for everything present in the GUI, but only when the developers of those interfaces make equivilent Monad commands... if they even do!

      In Unix, we simply have commands for everything. Period.

      The idea of turning a pipe into an object stream is sort of neat though, I'll admit that.

    3. Re:Please try Monad out by jsnover · · Score: 1
      >Monad however has to have everything written for it. You can't take your existing command line apps, or GUI apps, and intermix them to create new programs or script with what you have.

      We fixed this in the latest drop. We want Monad to be useful for Admins. That means that it has to address the problems they have today and provide them a substantial value proposition above and beyond that.

      In addition to being an interactive Shell, Monad supports 3 styles of scripting:
      1) *NIX style scripting (stitch together existing executables and provide a set of text processing utilities),
      2) VBScript style scripting (Manipulate OLE Automation objects),
      3) .NET style scripting (stitch together Cmdlets which produce/consume objects and provide a set of object processing utilities).

      You are right about the strength of UNIX - it has commands for everything (hats off to you). This is a weakness of the Windows world. Addressing this was one of the primary design centers for Monad. I believe economics talks and BS walks. Monad is designed to provide a maximal return on investment for Cmdlet developers. Monad is architected to make developing cmds very cheap and easy and once you do it, it provides a ton of functions.

    4. Re:Please try Monad out by Anonymous Coward · · Score: 0

      Last I checked it works fine with W2K pro, or at least the beta did. The only requirement is .NET 2.0.

    5. Re:Please try Monad out by julesh · · Score: 1

      I encourage you all to download the beta and let us know how we are doing

      Thanks. We might be able to help more if access to the beta was easier; many people here are cautious about giving their personal details to anyone, and the idea of a two day wait before we can start looking at it is a little offputting. Is there a faster and easier way of getting it?

    6. Re:Please try Monad out by Anonymous Coward · · Score: 0

      What you got wrong was working for a predatory company with no original ideas.

    7. Re:Please try Monad out by codepunk · · Score: 1

      Why, did I miss something, does it run on linux. I would not suggest my worst enemy run windows.

      --


      Got Code?
  47. If it's good.... by Anonymous Coward · · Score: 0
    It'll be ported to *nix in not time :)

    if not by microsoft then by enterprising OS advocates.

    1. Re:If it's good.... by EMH_Mark3 · · Score: 1

      It'll be ported to *nix in not time :)

      if not by microsoft then by enterprising OS advocates.

      Yeah, GNU/Monad... gonad for short.

      --
      Burn the land and boil the sea, you can't take the sky from me
    2. 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.

    3. Re:If it's good.... by mi · · Score: 3, Interesting
      It's rather sad to see people dismissing this so quickly.
      That's the weakness of the Microsoft brand. Whatever they do is usually designed poorly. Even when the design is Ok, the implementation is bad. Even if properly implemented, the thing will be crippled by several of -- at least -- the following:
      • having to support legacy concepts (such as drive letters);
      • licensing concerns (like XP workstation allowing only one user at a time);
      • wide-spread security concerns resulting in the feature being turned off by default on most installations;
      • wide-spread fears of accidental and intentional incompatability;
      • being only available as part of an expensive (and extensive!) upgrade;
      • etc.

      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.
    4. Re:If it's good.... by IamTheRealMike · · Score: 3, Insightful
      having to support legacy concepts (such as drive letters);

      Whilst the UNIX style unified directory hierarchy is aesthetically pleasing to computer scientists, I've never been convinced that it's really more usable. On Windows, people can learn a few simple letter to concept mappings "A" is the floppy disk, "C" is the stuff inside the Computer, "D" is the cD-rom drive, "E" is their usbEE kEE. Obviously not all systems will be like that, but it's common enough. On UNIX systems the location of floppy disks, installed programs, mounted USB keys and so on tend to move around unpredictably.

      Incidentally, talking of legacy concepts, what do you think "mounting" is? It dates from the time when you had to mount tapes onto their reels!

      licensing concerns (like XP workstation allowing only one user at a time);

      I don't see how this would affect a command shell designed for personal use. I also don't understand how it only allows one user at a time - in the copies of XP I've seen multiple users can log in at once, then you can rapidly switch between them. If you are thinking of X and terminal servers, well, you can have a command line without that. Look at MacOS.

      wide-spread security concerns resulting in the feature being turned off by default on most installations;

      There's no evidence I can see that suggests this would be off by default. Actually MSH could be a lot more secure than the UNIX shell as it can be fully controlled by .NET Code Access Security, which is more fine grained than traditional UNIX permissions.

      wide-spread fears of accidental and intentional incompatability;

      By adding a new end-user feature? That never stopped them adding themes, Media Player, MSN Messenger, etc. Compatibility concerns for something totally new are far less serious.

      being only available as part of an expensive (and extensive!) upgrade;

      In contrast to what? Microsoft backport far more stuff than Linux vendors do, and Apple basically doesn't backport anything at all. That's $120 per upgrade, thanks very much.

      Seriously. The guys working on MSH have blogs, I read a few, and they seemed very sharp to me. The MSH API seems quite lightweight and I suspect you'll be able to create new commandlets very easily - far easier than you can create new command line tools on Linux. Some of the examples they showed would require thousands of lines of code to write on Linux once you take into account the build system, the fact that they're usually written in C, the text parsing with extra checks for buffer overflows etc. Yet using the MSH API they fitted onto a single screen of text.

      I'm not too worried, I don't use Linux over Windows just because of bash (surprise), I use it because it's Free (and it has some other neat features I like). Actually, most UNIX shells suck ass. Their builtin programming languages are hideously primitive, unintuitive, and are easy to screw up. Getting basic information out of common tools requires a guru-level knowledge of sed, awk and Perl style regular expressions which are themselves primitive, backwards and unintuitive.

      You'd have to work pretty hard to produce a command line worse than the UNIX one (and no, cmd.exe does not count as "working hard", I suspect it's had about a weeks worth of work in the last decade).

    5. Re:If it's good.... by Anonymous Coward · · Score: 0

      That's the weakness of the Microsoft brand. Whatever they do is usually designed poorly.

      You mean like the rc system?

      Even when the design is Ok, the implementation is bad.

      You mean like gcc, which couldn't deliver optimized executables if it's life depended on it, even after being rewritten to have a clean and powerful design?

      Even if properly implemented, the thing will be crippled by several of -- at least -- the following:
      having to support legacy concepts (such as drive letters);
      /bin, /usr, ... the whole fricking /etc dir and all its lame formats.

      licensing concerns (like XP workstation allowing only one user at a time);

      Yeah, because you can run a single license of redhat linux on as many servers as you want, and there are absolutely no *nix products that have limitations on how many clients can connect.

      wide-spread security concerns resulting in the feature being turned off by default on most installations;

      Like how most distro's are moving to a policy of no services after a default install? And have you looked at security bug lists? *nix is not doing much better than windows, even if you make a fair count of it.

      wide-spread fears of accidental and intentional incompatability;

      Fine, this one I'll grant you. But most of the time they're just fears. MS breaks protocols a lot less than people think they do.

      being only available as part of an expensive (and extensive!) upgrade;

      No difference from commercial linux distro land, where you are regularly forced to upgrade as well.

      Frankly, I don't like MS, but they seem to have moved on from the bitching and moaning to fixing what's wrong with their systems. There are not a lot of things anymore which linux does better than windows, and every month there are less. If the FOSS crowd doesn't start actually improving their OS's by dramatic architectural redesign and improvement, they're going to be eclipsed by MS, even in the server space. And that would truly be pathetic.

    6. Re:If it's good.... by cahiha · · Score: 1

      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

      Yeah, but that wouldn't make it any better either.

    7. Re:If it's good.... by mi · · Score: 2, Interesting
      Whilst the UNIX style unified directory hierarchy is aesthetically pleasing to computer scientists, I've never been convinced that it's really more usable. On Windows, people can learn a few simple letter to concept mappings "A" is the floppy disk, "C" is the stuff inside the Computer, "D" is the cD-rom drive, "E" is their usbEE kEE. Obviously not all systems will be like that, but it's common enough. On UNIX systems the location of floppy disks, installed programs, mounted USB keys and so on tend to move around unpredictably.

      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.

      licensing concerns (like XP workstation allowing only one user at a time);
      I don't see how this would affect a command shell designed for personal use.
      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.
      Microsoft backport far more stuff than Linux vendors do
      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.
      The guys working on MSH have blogs, I read a few, and they seemed very sharp to me.
      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.
    8. Re:If it's good.... by TrancePhreak · · Score: 1

      cmd.com does loops, and passes arguments... You can even build loops that do counting and pass the values as arguements.

      --

      -]Phreak Out[-
    9. Re:If it's good.... by fingerfucker · · Score: 1

      That would be hard, MSH leverages .NET quite extensively. You might see a Mono Shell, or a Python Shell using the same concepts though.

      Not really. To implement object pipelining instead of textual output pipelining, they will be utilizing .NET reflection.

      Reflection is nothing new, obviously. It's the fact that they leverage a fully object-oriented language and the reflection part of its API to implement object-piping scripting language, that's the real innovation in here.

      Simply put, it's how you put the wheels together, not the wheels themselves.

    10. Re:If it's good.... by mi · · Score: 1

      Can you post the equivalent of sh's "$@" and some examples of loop syntax? Thanks!

      --
      In Soviet Washington the swamp drains you.
    11. Re:If it's good.... by IamTheRealMike · · Score: 1
      To navigate to /cdrom you have to be exposed to the full legacy horror of the filing system heirarchy standard: /etc /usr/ opt/ /boot /sys /proc .... these names are even more meaningless than System or Program Files. And most distros don't put it in /cdrom. They put it in /mnt/cdrom, or maybe /media/cdrom, or maybe it's not actually in your fstab at all and you have to manually mount it somewhere by knowing its device node.

      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.

      How arrogant. I've done enough coding, and learned enough about usability, to know when somebody is making excuses about something that may have made sense 20 years ago but no longer does.

      Now I'm not saying we should replace the unified heirarchy with driver letters on Linux, rather the way GNOME is going with showing multiple "roots" in the UI labelled by logical device names is a better approach. The UI is basically the same, in the new GTK+ file picker you have "Filesystem", "Home", "Desktop", "CD/DVD Drive" etc and they're mapped behind the scenes to wherever they're mounted.

    12. Re:If it's good.... by mi · · Score: 1
      Ok, thanks, that link has some loop examples, but no equivalent of shell's "$@". Would you try again, or agree (for the record), that this functionality is missing?

      Just in case you don't know, what I'm talking about, "$@" are all the arguments given to the script in one list. For example, the following wrapper can replace any program (which should first be renamed into program.bin):

      #!/bin/sh
      # Log the invocation of the program:
      logger "Executing $0 with the arguments $@"
      # Execute the original utility:
      exec "$0.bin" "$@"

      Can cmd.exe do this?

      --
      In Soviet Washington the swamp drains you.
  48. Drive letters by mkithara · · Score: 1

    In MSH, drive letters become a bit more complex, as they provide mapping for filesystems, the registry, and more.

    sl HKLM:\Software\Microsoft\Windows\CurrentVersion
    ( set-location / cd)
    gci
    (get-childitem / dir)

    1. Re:Drive letters by Zancarius · · Score: 1
      sl HKLM:\Software\Microsoft\Windows\CurrentVersion
      ( set-location / cd)

      Everytime I see sl, I can't help but think of this.
      --
      He who has no .plan has small finger. ~ Confucius on UNIX
  49. Never heard of 4NT? by Anonymous Coward · · Score: 0

    http://www.jpsoft.com/

    4NT has been available for many years (even back to the DOS days as 4DOS) and is an excellent shell both interactively and for scripting. To mention only Cygwin shows the UNIX tunnel vision pervasive on /.

  50. why not cygwin? by bokmann · · Score: 1, Interesting

    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.

    1. Re:why not cygwin? by Anonymous Coward · · Score: 0

      You're stupid. You're talking about Windows SFU, which is better implemented than cygwin (though the userland tools are not as good). This time, MS wanted to create a shell that is better. Maybe they have succeeded.

    2. Re:why not cygwin? by Anonymous Coward · · Score: 0

      Everything people want out of a shell? How about tab completion that makes sense, command names that make sense, command options that make sense, directory structure naming that make sense.

      cygwin/bash is hopelessly arcane due to being a copy of unix.

      And even if you gave cygwin all that, it's still as limited as a unix shell - doesn't nicely interact with running applications for example

    3. Re:why not cygwin? by julesh · · Score: 1

      Try reading the article. What they're providing here is nothing like bash, just as its nothing like the cmd.exe shell in current windows versions. It's an object-array-oriented, rather than stream-oriented shell. It's an interesting idea, and many of us are looking forward to seeing how it pans out. I also bet we'll be seeing similar ideas implemented for Linux in the near future.

  51. 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
    1. Re:Ok, ok... fun's over--seriously now... by ignatz72 · · Score: 1

      MS is not reinventing UNIX.

      No, they are not, they are adding things that should have been there years ago...

      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.

      This fits into a discussion about CMD line tools how? Thanks mr. N(on) Sequitor

    2. Re:Ok, ok... fun's over--seriously now... by nightcrawler.36 · · Score: 1

      So what? they're putting them in there now! Who cares when they're doing it--why is it such a big deal?

      --
      - nightcrawler "Reality is an illusion, albeit a ver persistent one..." -A.Einstein
  52. Re: Unix depreciated by Anonymous Coward · · Score: 0

    Well Unix is already getting depreciated! It started by *BSD. Netcraft confirms.

  53. Can't believe slashdot doesn't know monads by Anonymous Coward · · Score: 0

    Lookup monads in haskell and other functional languages. They're constructs which are particularly useful in I/O. I'm not that familiar with them, but I know enough to know that whoever is behind his Monad shell may just be on to something.
    I'd really hate to lose the command line war to Microsoft, after unix/linux having been dominant for so long.
    -fooburger

  54. Ever tried rundll? by daBass · · Score: 1

    You'd be amazed hoe much of windows's functionality "hidden" in DLLs is actualy available through rundll.exe, you just need to know how to access it. (which is where the Windows Resource Kit comes in, I believe)

    I can only imagine this is because the people that write these DLLs like testing them before the GUI is implemented by another team. Kinda like how many Java developers like to put main() methods in every other class to quickly test it's functioning on it's own.

  55. What a great blowoff by Urusai · · Score: 1

    Everyone who does anything computer/OS-related is just "reinventing Unix poorly". Why, even those newfangled *BSDs are just ripoffs of the original. In fact, if you aren't using punchcards and a PDP-11 to run your OS, you are just a no-talent assmonkey.

  56. Sounds nice. Does it run on Linux? by ShyGuy91284 · · Score: 1

    Seriously though. It would be interesting if M$ implemented their shells on other platforms to expand the number of people knowledgable with them (Since Windows is mainly GUI based, I'm guessing more people know *nix shells then Windows shells). And I'd give it a try if I didn't have to go over to Windows....

    --
    In undeveloped countries, the consumer controls the market. In capitalist America, the market controls you.
  57. The Longtooth Post, Streamlined Edition by rice_burners_suck · · Score: 0, Troll
    The Longtooth Post can now be found on its own web site, due to popular demand. Here is the portion relevant to this story:

    Microsauft will address the security problem through a variety of changes to the Longtooth codebase. First, as I mentioned in the past, Longtooth will no longer be based on the NT design philosophy, as were previous versions. Instead, Microsauft plans to release DOS 9.0 2003, an 8-bit multithreaded DOS written in VB Server.NOT. Longtooth will run somewhere on top of that, above several hundred layers of abstraction and a thunking mechanism to convert 64-bit calls to 32-bit calls to 16-bit calls to 8-bit calls to 4-bit calls and then back to the 8-bit calls required by DOS 9.0 2003. The DOS syntax will be completely changed into a format significantly more complicated than the bash, csh, sed, awk, perl, m4, and makefile formats used in Linux and UNIX operating systems. These changes will add significant complexity to the command line, providing Microsauft a basis to claim that the Longtooth command line is more powerful than its Linux counterparts. It will also intimidate most users, giving Microsauft ample reasons to tout its Microsauft User Simplicity and Security Manager 2003 as the most innovative thing since sliced cucumber.

    As an example of the new syntax, suppose you wish to view the contents of a directory. In the old DOS, you would use the terse and ineffective "DIR" command. With Longtooth, you will be able to use the much more capable command, "DIR-print (sed /e:++ : a--$ C$$ awk | lesstif (+, +, +, +) at 0900+W+ $ while (w--- O- M+ V-- S++$) { P++>$ x++ }) >>display | formatTabulated".

  58. you know it sucks when... by popra · · Score: 0, Troll
    1. Re:you know it sucks when... by Anonymous Coward · · Score: 0

      Are you kidding, the unix shells suck, and cygwin is the same.

      This is interesting, if I were to design a new command line for windows I would have listed everything broken and unfixable with the unix shells then devised something without those problems, while learning a bigger lesson from unix and making the thing flexible for future expansion, as well the Apple lesson that unix still doesn't get - UI is #1 (what the hell kind of command is apropos?)

      But this goes a step further - they appear to be expanding the realm of the command line, it's not some fixed unix shell that's user friendly and extendable, but a more powerful OO concept of shell.

      Will be interesting to see how well it works.

    2. Re:you know it sucks when... by Anonymous Coward · · Score: 0

      hmm, re-reading that, it's a bit inflamitory, my apologies.

      What I meant is there are a lot of limitations and serious things wrong with the unix shells, and rather than saying "why doesn't Windows just get a unix like shell", they're choosing a new CUI concept, I think this is breath of fresh air and very encouraging.

    3. Re:you know it sucks when... by popra · · Score: 0

      right!
      btw ... monad comes from the same people that said the days of command line are over and M$ will not invest any further into such utterly useless things, especialy, when they have their nice and very usefull GUI(this happend a few years back... googleit). Flames go to M$ because of the way it thinks and because of its never ending hypocrite ways, not because of the quality of their work... which will undoubtedly suck too

      so, thanks for your 2 dime oppinion, and thanks for standing by it ... anonymously ... morron ...

    4. Re:you know it sucks when... by julesh · · Score: 1

      a port of a similar linux app. already exists for win32

      Have you read the article? This is nothing like cygwin/bash.

    5. Re:you know it sucks when... by popra · · Score: 0

      As any other user, I sould not be concerned with the inner workings of the software I use, and so I care very little about their new buzzword technology. The whole point of adding a layer like this between user and OS is just that... to not concern the user with technical mumbo jumbo, because otherwhise I could just get my VC++ and write some damn app that does the exact same thing.
      And before even thinking of saying monad would be faster stop and think for a sec. about all the alternatives the linux eviroment gives you (and by association cygwin) to accomplish a task, and when you thought about all of them let me know what you think.

  59. So how can I install that on Linux? by RedLaggedTeut · · Score: 0, Redundant

    Can't find the download link ..

    --
    I'm still trying to figure out what people mean by 'social skills' here.
  60. Fist object oriented shell. by Anonymous Coward · · Score: 0
    "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 the fuck where you trying to say?

    If this is the lanugage I have to use to run commands in the Monad shell, no thanks.

    1. Re:Fist object oriented shell. by Anonymous Coward · · Score: 2, Informative

      What the fuck where you trying to say?.

      Not to be pedantic about your pedantry, but I think you meant were, not where.

  61. Anybody got the download URL? by freshtonic · · Score: 1

    ... the Channel 9 Wiki seems to be dead. Cheers!

  62. Re:strings for piping by eurleif · · Score: 1

    Right: they're byte strings. Strings aren't just text.

  63. Cool! by TheStick · · Score: 1
    Now we can trick newbies into typing:

    su -c "rm -rf c:"

    Sweet!

  64. from the google cache by Anonymous Coward · · Score: 1, Informative

    How Can I get MSH?

    To get MSH, first navigate to http://beta.microsoft.com/ and logon using Passport. Then, click where indicated just after the text "If you were issued a guest ID by Microsoft you can sign in" then enter the guest id of mshPDC (this is case sensitive!). You the need to enter your details and you should get beta details back within a couple of days with site access to the MSH bits.

  65. Tech-Recipe link by Oriumpor · · Score: 1
    1. Re:Tech-Recipe link by Anonymous Coward · · Score: 0

      Also, the article is over 8 months old, but seems to still be accurate.

  66. Warning: FAKE screen shot by Anonymous Coward · · Score: 0

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

    C:\>


    The proof is in the copyright.

    1. Re:Warning: FAKE screen shot by Ravatar · · Score: 1
      Yea, everyone knows THIS is the real MSH.
      Microsoft Command Shell [6.0.4093.0]
      Copyright (c) Microsoft Corporation. All rights reserved.

      MSH>
    2. Re:Warning: FAKE screen shot by DarkEdgeX · · Score: 1
      You must have an older build. The most recent build from just a week or two ago starts out like this--
      Microsoft Command Shell
      Copyright (C) 2005 Microsoft Corporation. All rights reserved.

      MSH>
      --
      All I know about Bush is I had a good job when Clinton was president.
    3. Re:Warning: FAKE screen shot by Ravatar · · Score: 1

      Yeah, probably. I've been using the same build for about 4-5 months, guess it's time to update :P

  67. In particular read... by exp(pi*sqrt(163)) · · Score: 1

    ...this.

    --
    Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
  68. I checked it out by trezor · · Score: 1

    Seems to be able to do a somewhat decent task, but for reasons not given junction points do not, unlike the rest of the FS, support Unicode-characters.

    Arrg!

    --
    Not Buzzword 2.0 compliant. Please speak english.
    1. Re:I checked it out by Man+Eating+Duck · · Score: 1

      ...for reasons not given junction points do not, unlike the rest of the FS, support Unicode-characters.

      Oh DAMN, so that is the reason!

      Here I have been literally tearing my hair out trying to configure mount_smbfs on FreeBSD to mount a W2k-share with Unicode chars.

      I never figured the filenames were actually being mangled in the junction on the W2kPro box.

      Well, FWIW, apart from that little feature the junctions themselves work reliably.
      --
      Are you a grammar Nazi? I'm trying to improve my English; please correct my errors! :)
  69. Wohoo! by Dasch · · Score: 1

    See the new Star Wars movie - success
    Kiss the hottest babe in school - failure
    Stay up all night to script - check /. MSDN - check

    Slashdot just saved my day!

  70. Does this mean? by janus_god · · Score: 3, Funny

    Does this mean that tracert will become traceroute and dir become ls? Good god the implecations are huge.

    1. Re:Does this mean? by SpinJaunt · · Score: 1

      I guess implecations becomes implications?

      --
      /. is good for you.
  71. 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.

  72. Monad is NOT Coming by sjvn · · Score: 1

    Look at the Wiki's date guys. The Channel 9 page was updated late last year.

    Since then, it's been revealed that Monad will not be in Longhorn--whenever the heck that will come out--but will show up in Exchange 12 say sometime in 2007.

    Don't ask me what a command shell will be doing in an e-mail server.

    For the details see the following article from: Mary Jo Foley's Microsoft Watch

    From where I sit, Monad was a decent idea. With it gone, I see even less reason than before to upgrade to XP SP3, excuse me, Longhorn.

    Steven

    1. Re:Monad is NOT Coming by Anonymous Coward · · Score: 0

      Don't ask me what a command shell will be doing in an e-mail server.

      It has to do with security, I'm sure, or, more likely, the lack thereof.

    2. Re:Monad is NOT Coming by Anonymous Coward · · Score: 0

      By the way, Steven, that sure was a nice straw man you set up in your last op piece on eweek. I mean, framing your article as if you would ever consider upgrading to Longhorn in the first place was just pure gold - you'd never do it anyway, but it made you appear like you could actually treat the subject rationally. Genius.

      All of us totally fell for it, of course. The fact that many of us would never consider using the piece of shit OS that you openly pimp for is beside the point. Oh dear - did my blatant bias put you off the point of my post? Wow - maybe you're experiencing the same feelings of wry contempt that some people experience when reading your opinion pieces. Ho hum.

  73. Whoosh! Bwahahaha! by screwthemoderators · · Score: 1

    I'm sure WinXP won't delete itself. DOS would easily fit into ram (from floppy disk even) so it was easier to do things like wipe out the C: drive. (it was a Disk Operating System, after all) It might be interesting to list the ways NT protects against such old script-kiddie (batchfile-kiddie?) pranks.

    1. Re:Whoosh! Bwahahaha! by moonbender · · Score: 1

      Actually, there was a story or comment on Slashdot a while ago where somebody tried formatting/erasing the system partition both in Windows and in Linux. If I recall correctly, both systems were in a non-bootable state after a recursive delete, although they kept running for a while.

      --
      Switch back to Slashdot's D1 system.
  74. all I can say is... by enrico_suave · · Score: 0, Redundant

    thank god microsoft wasn't founded as gicrosoft.

    I would not use a "Gonad" CLI

    =P

    e.

    --
    Build Your Own PVR/HTPC news, reviews, &
  75. Name when released by the GNOME team: by Bob_Robertson · · Score: 1

    Gonad

    Aww, just trying to lighten the mood. Microsoft can write anything they want for their OS and for their customers. I applaud their recognition that a command line is worth having.

    In doing so, I think Microsoft is admitting that wizards cannot do everything, that a command line is worth having. It's the only way under windows I've ever known to get the information from "C:\route print"

    Bob-

    --
    The Ludwig von Mises Institute. The reasoning individuals economics
  76. cmd line or not... by ignatz72 · · Score: 1

    all your monad are ./

  77. welcome by Anonymous Coward · · Score: 1, Insightful

    (warning, broken english ahead)

    Personally, I'm glad to see this.

    I don't undersand the critics, it seems a nice and useful and expressive tool for "power users" (yes, I presently run cygwin on every win-pc i have access to...), with the chance of being pretty elegant, too.

    shame on us "advanced" linux/unix users, the object-scripting tecnology is available now in several incarnations (my preference goes to Ruby) but we refuse to introduce new standards, we rely costantly on what has been decided at least a decade ago. we joke about the so called "microsoft boldness", but i think we don't have a much better attitude if we prefer to act a bit too much as if we were a bunch of uncoordinated people lacking trust on ourselves....

    it's obvious that this way our "environment of choice" can't be appealing to most of the new developers, both at individual level and company level...

    and for what concern a cross-language vm, parrot isn't finished yet.

    better wake up NOW, or our preferred environment is going to die quite quickly.

    as for microsoft latest advances, i praise them, as i would do if the company name was different. it's nice to see that some company is still making investments in the server and desktop market.

  78. anagram for MONAD by Anonymous Coward · · Score: 0

    MONAD --> DAM NO.

  79. 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.
    1. Re:30 years in computer years? About 1000 years by SA+Stevens · · Score: 1

      It HAS been designed 'many times over' in the last few decades.

      Or are you running /bin/sh (No! Not an alias to bash, that doesn't count!) as your Unix shell?

      I prefer /bin/csh but use sh for some things.

    2. Re:30 years in computer years? About 1000 years by Moderation+abuser · · Score: 1

      A shell script from 30 years ago will run on a current /bin/sh. If you sit a 70 year old unix user from 30 years ago down in front of a terminal or terminal emulator they will be right at home.

      So while the binaries change, the design is the same.

      --
      Government of the people, by corporate executives, for corporate profits.
    3. Re:30 years in computer years? About 1000 years by rcamera · · Score: 2, Interesting

      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
    4. Re:30 years in computer years? About 1000 years by Matt_Joyce · · Score: 1


      erm, querty keyboards.

      Just becuase something is old, loved and usable, does not make it necessarily best.

    5. Re:30 years in computer years? About 1000 years by Anonymous Coward · · Score: 0

      It withstood the test of time also because no alternative came along that offered enough improvement over status quo to make the switching costs worthwhile to a critical mass of users...

      It sounds like MSH has a lot of good ideas that would make it a more powerful and easier environemnt to use. And, it comes from Microsoft which already has a large following and is quite adept at education and marketing to get users.

      They might not get it right on the first release, but when they finally get it done right, there will be a large and ethusiastic userbase...

    6. Re:30 years in computer years? About 1000 years by lackita · · Score: 1

      I can't resist the temptation to point out that you can't even spell qwerty correctly.

  80. lol, personalized error ... by da5idnetlimit.com · · Score: 3, Funny

    "Server Error in '/' Application."

    Is computing really becoming pervasive ?
    At least it has a sense of humor 8)

    'Server Error in '/' Application.

    Runtime Error
    Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.

    Details: To enable the details of this specific error message to be viewable on remote machines, please create a tag within a "web.config" configuration file located in the root directory of the current web application. This tag should then have its "mode" attribute set to "Off".

    Notes: The current error page you are seeing can be replaced by a custom error page by modifying the "defaultRedirect" attribute of the application's configuration tag to point to a custom error page URL.

    '

    --
    It takes 40+ muscles to frown, but only four to extend your arm and bitchslap the motherfucker
  81. Transcendent got OWNED! by Anonymous Coward · · Score: 0

    lol

    Someone doesn't know jack.

  82. JP Software by Kevin108 · · Score: 0

    Think they'll update 4DOS?

    --

    It's a perfect time for being wasted.
    A perfect time to watch the stars.
    - Burden Brothers, "Beautiful Night"
  83. 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.
    1. Re:what can UNIX learn from this? by The+Cookie+Monster · · Score: 2, Interesting
      They implement some subset that's good enough for the job at hand and tweak it when it screws up
      You're right on the money, but it hasn't worked well for decades, it's meant new changes can't be introduced to the system as everythings breaks.

      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.
    2. Re:what can UNIX learn from this? by marcosdumay · · Score: 1

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

      We would need a hole new convention on how to serialize those objects (A faster XML?). Also, it is not so clear if it would be an advantaje or if it will reduce the usefullnes of the CLI, because every use must be though at programming time (like GUI)

      I think it worth trying, but I am not sure if it will be a good experience.

    3. Re:what can UNIX learn from this? by julesh · · Score: 1

      every use must be though at programming time (like GUI)

      I'm not sure why you say this. Can you explain a little more? I would have thought that any use could be supported that can be done with the current system. If necessary, just fall back on objects containing a single string representing a line of text, and processing as you would currently, but I don't think there are many situations where this would be necessary.

      S-expressions, while nasty for humans to work with, would be a reasonable interchange format.

    4. Re:what can UNIX learn from this? by moonbender · · Score: 1

      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.

      While you might be right about that, long (or nice) names have an additional benefit apart. To borrow terms from general interface design, they have a better discoverability, or in yet different terms, they are somewhat self-documenting. This is extremely powerful: when developing Java an IDE with auto-complete is often enough to figure out what objects to use and which methods do what you want. Obviously this doesn't replace decent documentation, but it helps a lot when you're starting out in a new field.

      This is what other have (mis)named intuitive. Long command names aren't exactly intuitive, but they are somewhat self-documenting. Along with shell command line auto-complete (or even just a list of available commands) I'm pretty sure any reasonably experienced user would find something like get-process faster than ps.

      PS - I realize this wasn't anything like the main point of your post, sorry for picking out the first paragraph...

      --
      Switch back to Slashdot's D1 system.
    5. Re:what can UNIX learn from this? by pentalive · · Score: 1

      do you mean...

      ls -monad
      filename="."
      owner="jruser"
      isdir="true"
      ownerread="true"
      ownerwrite="true"
      ownerexecut e="true"....

      Every shell tool would recognise -monad output and be able to parse the fieldnames so you could:

      ls -monad | grep isdir=true | sort filename | show_as_list

      If a shell tool sees a -monad input, it produces -monad output so -monad would only have to be used on the source command.

      Somthing like this??

    6. Re:what can UNIX learn from this? by cahiha · · Score: 1

      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's what UNIX applications do: they transmit streams of records. Each record is separated from the next by record separator (usually one or two newlines), and the fields within each record are separated by a user-definable field separator.

      It's well defined and it works.

    7. Re:what can UNIX learn from this? by ArbitraryConstant · · Score: 1

      "We would need a hole new convention on how to serialize those objects (A faster XML?)."

      I thought about it a little. XML is the obvious choice, but that might be overkill. The parser shouldn't need to be recursive like it would need to be with XML. Instead of lines, there could be objects that are nothing but key:value pairs, dictionaries basically.

      "Also, it is not so clear if it would be an advantage or if it will reduce the usefullnes of the CLI, because every use must be though at programming time (like GUI)"

      No, I don't agree.

      As a trivial example, consider an "ls" equivilant. In this example, the first line describes the fields and their types. I'm leaving out a lot of stuff for brevity, but you'd want it to give you everything that stat returns.

      $ list-dir .
      name:string,size:int,directory:bool,read:bool,w rit e:bool,execute:bool
      CVS,512,Y,Y,Y,Y
      Makefile,712 ,N,Y,Y,N
      main.c,10231,N,Y,Y,N
      a.out,12783,N,Y,Y, Y
      $ list-dir . | filter name -eq Makefile
      Makefile,712,N,Y,Y,N
      $ list-dir . | filter name -eq Makefile | format "%s: %s" name size
      Makefile: 712


      Now say I have something else. As a contrived example, I have a file containing phone numbers, I'm not saying grep wouldn't be better for such a simple task, this is just an example of how something like this might work, to show that it's general purpose. I use Python regexes in this example because they can have named groups.

      $ cat numbers.txt
      Alice: 111-1111
      Bob: 222-2222
      $ cat numbers.txt | parse "(?P<name>.*?): (?P<number>[0-9]{3}-[0-9]{4})"
      name:string,number :string
      Alice,111-1111
      Bob,222-2222
      $ cat numbers.txt | parse "(?P<name>.*?): (?P<number>[0-9]{3}-[0-9]{4})" | filter name -eq Bob | format "%s" number
      222-2222
      $ cat numbers.txt | parse "(?P<name>.*?): (?P<number>[0-9]{3}-[0-9]{4})" | filter name -eq Bob | format-args number -- dialer-program
      dialing...


      Something like this would make much more powerful scripts possible. Languages like Python are very powerful, but they're not shell replacements. You want to pack the maximum punch into a the shell.

      --
      I rarely criticize things I don't care about.
    8. Re:what can UNIX learn from this? by SharpFang · · Score: 1

      Separating fields by whitespaces or commas, records by EOLs, being done for ages now. Most "list" commands create such serializable data, this is what we see. list whole dir structure, grep records containing .c in last field, extract column with filesizes, add up the values with bc and you have amount of C sources. It exists.

      --
      45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
    9. Re:what can UNIX learn from this? by ArbitraryConstant · · Score: 1

      Yes, but shell tools don't do it and aren't aware of it, for the most part. You end up having to munge text with sed or similar to pull stuff out.

      --
      I rarely criticize things I don't care about.
    10. Re:what can UNIX learn from this? by ArbitraryConstant · · Score: 1

      That's a lot harder for some operations. It's fine if the output of the tool is columns but sometimes it isn't, or it's a more complicated format. It puts a lot of the parsing work on you. Shell tools that share a compatible protocol would make it a lot easier to write some sorts of scripts.

      --
      I rarely criticize things I don't care about.
    11. Re:what can UNIX learn from this? by ArbitraryConstant · · Score: 1

      "Somthing like this??"

      Pretty much what I was thinking, year. I don't know if you'd want to call it -monad, but that's the general idea.

      --
      I rarely criticize things I don't care about.
    12. Re:what can UNIX learn from this? by Lorkki · · Score: 1
      No, this highlights a weakness in UNIX shells: we have to parse things. It's slow and it's a huge pain.

      Well, most of actual parsing is done by the tools that act on the data. The rest is just application of the results to whatever traverses down the pipe. The overhead from this not particularly significant, considering that with Monad you also have to have a functional framework - essentially another abstraction layer - for passing around those objects.

    13. Re:what can UNIX learn from this? by cahiha · · Score: 1

      awk, sh, join, cut, paste, perl, grep, xargs, sort, and lots of other programs can manipulate data streams in exactly that format. And many UNIX tools are designed to generate data in that format: ls, df, ps, etc. Log files, daemons, and many kinds of data are also in that format.

      More recent command line tools and file formats, unfortunately, deviate from that traditional format, sometimes because their authors just didn't understand and sometimes because they come from Windows.

    14. Re:what can UNIX learn from this? by DaveCar · · Score: 1

      What's an alternative? Serialize the data structure

      Well, it kinda works for XML. I can serialise that, pass it through a buch of funky XSLTs and end up with some neat-o HTML, PDF or text happily enough.

      I suspect there is very little that needs to be changed about the shell itself. I could see some utils (yeah, maybe even builtins) which would allow you to work with applications along the lines of OLE (or whatever it is them thar windows boxes use) would be quite useful.

    15. Re:what can UNIX learn from this? by marcosdumay · · Score: 1

      "No, I don't agree."

      And you are not the only one. Thinking a little more, I guess I wasn't right about this. It'll probably be usefull.

      About the conventions, yes, XML is overkill (I sugested something faster), but just pairs key:value aren't enogh. Maybe, what is missing here is some type declaration, where the types define keys and their values are on the key:value pairs. That will make objects that contain other objects possible and would still be fast to parse.

      Another point is that the terminal may know how to display the data if you declare its type, so the 'format' step would not be necessary.

      All this seems to be a very interesting project!

    16. Re:what can UNIX learn from this? by ArbitraryConstant · · Score: 1

      "Maybe, what is missing here is some type declaration, where the types define keys and their values are on the key:value pairs. That will make objects that contain other objects possible and would still be fast to parse."

      That would be recursive, requiring a recursive parser. I think a much simpler parser would be better, but it might ultimately be necessary to do more. Of course, if it's that complicated you should probably use a better language...

      "Another point is that the terminal may know how to display the data if you declare its type, so the 'format' step would not be necessary."

      The serialization library could detect if the output was a TTY, and output a slightly more human readable output.

      --
      I rarely criticize things I don't care about.
  84. modded down for speaking badly about my own post by bersl2 · · Score: 2, Funny

    WTF?

    I need sleep...

  85. Mono? by Anonymous Coward · · Score: 0

    So if this is supposed to just be a text inferface on .NET, then when is Mono going to try to support and/or recreate this?

    Monoid?

  86. Strange by Anonymous Coward · · Score: 0

    I was outside, and a squirrel started singing "Monad and strife..."

  87. MOD PARENT INSIGHTFUL! by Anonymous Coward · · Score: 0

    Absolutely spot-on.

  88. massive case of second system effect by cahiha · · Score: 3, Interesting

    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.

  89. Drop the marketing jargon for a minute! by Zancarius · · Score: 1, Interesting

    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 .plan has small finger. ~ Confucius on UNIX
    1. 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.
    2. Re:Drop the marketing jargon for a minute! by Anonymous+Brave+Guy · · Score: 1
      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? [...] 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.

      Microsoft has provided basic scripting via batch files for years. If you want more than that, they've provided WSH for years, too, or (like the systems at every employer I've ever worked at, and like every home system I've configured in the past decade) you could just install a scripting language like Perl, which blows away any *nix command line shell anyway. I don't know where all this missing stuff the Windows-haters keep complaining about is supposed to be, nor what the market for it is.

      The advantage of Monad is precisely that it isn't just another CLI with a few twiddles. It can, for example, be tied into the .Net framework, and thus drive all the automation features that might be provided by any .Net-based application. That's orders of magnitude more powerful than a few command-line twiddles using regexps and pipes, which is pretty much all we've had before on either *nix or Windows until you start using a serious programming language rather than $SHELL_OF_CHOICE.

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    3. Re:Drop the marketing jargon for a minute! by iserlohn · · Score: 1
      and like every home system I've configured in the past decade) you could just install a scripting language like Perl, which blows away any *nix command line shell anyway.
      Which is why MSH really isn't anything new. There's a reason we're not using some variant of the python interactive console as the shell. First, not everything is written in python. Second, changing the semantics from a simple file-based one to a intricate let's-pass-around-objects one is counterproductive in a shell environment when you have a thousand different programs that can interface with each other.
    4. Re:Drop the marketing jargon for a minute! by Zancarius · · Score: 1

      [...] snip
      Ships with every Windows post 2000, I think.


      Okay, I'll confess that I was wrong about the lack of a kill command. I just looked this up through the ridiculously idiot-centric help system and noticed:

      Taskkill is a replacement for the Kill tool.

      Great. What was so wrong with "kill" that it had to be replaced by "taskkill?" I understand the intent to create a more self-descriptive tool, but I also think that my mistake has proved my point in a somewhat circular manner.

      What I mean by this is that the architecture of the default Windows CLI is absurd. I still stand by my claim that it is also anemic. The point of having a CLI is that commands can be dispatched to the system quickly and efficiently--increased verbosity in the terminology and syntax just requires more typing, which might be an attempt to further discourage users/administrators from using the CLI. The help system is also very awful--in spite of my apprehension toward manpages when I was first introduced to them, I now believe they are much easier and more effective to use than Windows' help.

      Admittedly, I don't use cmd.exe at all, or at least I try to minimize my usage of it to something far less painful. On my Windows install, the MS command prompt is replaced with a shortcut to rxvt in turn running bash. What this proves to me is that Microsoft's reinventing the wheel isn't really going to accomplish much; part of the point of my original post was to comment on this. Your correction of my error just proves this--taskkill is no more intuitive than kill and there is no good reason to replace the latter with something twice as many characters in length. I'm also fairly certain that a majority of Windows admins probably have no idea about the utility (I didn't--but I don't run Windows as a server, either, only for games), opting to use the Task Manager instead.

      In either case, the premise of the debate is still fairly well-proved. There aren't a lot of people who use cmd.exe in the first place because it lacks all the features of a decent shell. Additionally, what's the point of a userland utility like taskkill or tasklist when MSH is going to simple replace it with a get-process or other purportedly more intuitive commands? There is a reason you and I both install cygwin--and it's because of the power of bash/proven shells.

      (I also dislike the net command--but that is more of a personal preference. The idea has merit but the command and its structure are far too monolithic.)

      --
      He who has no .plan has small finger. ~ Confucius on UNIX
    5. Re:Drop the marketing jargon for a minute! by Zancarius · · Score: 1
      Microsoft has provided basic scripting via batch files for years. If you want more than that, they've provided WSH for years
      ...and we all know how much of a wonderful success WSH is. batch files are rather queer in their design, simply because they are more useful for setting the environment or creating a shortcut to launch an application. Beyond that, they're pretty much useless. WSH is a tremendous failure, IMO, because of the proprietary syntax. With as long as WSH has been available, I don't see it in as wide-spread use (outside trojan/worm exploitations, of course) as more powerful languages.

      The advantage of Monad is precisely that it isn't just another CLI with a few twiddles. It can, for example, be tied into the .Net framework, and thus drive all the automation features that might be provided by any .Net-based application.

      As could anything else. Python has provided interfaces to the win32 environment for years, and I'm sure .NET is no different. Just because a CLI offers this sort of flexibility doesn't make it much more innovative than adding this same support into the interactive interpreter of a language like Python. (Although I think iserlohn put it best when he illustrated exactly why MSH is a ridiculous idea.)

      MSH has some merit to it but it is neither innovative nor a bash/sh/et al killer. bash and family are powerful precisely because of their simplicity. Complex features and functionality is passed off to the userland. Integrating features and functionality directly into the shell is a recipe for disaster.
      --
      He who has no .plan has small finger. ~ Confucius on UNIX
    6. Re:Drop the marketing jargon for a minute! by Gorath99 · · Score: 2, Interesting

      Actually, if you're using WSH and not batch files (and there's no reason why you shouldn't on win2000 and up), the scripting really isn't that bad. In fact, it's much nicer than scripting in bash with its awful syntax and near-inability to cope with data containing spaces. Damn powerful too as long as your apps expose meaningful DCOM objects. (Most MS apps do nowadays.)

      I still script quite a bit in bash, since it's simply more portable, but scripting in Windows really isn't all that painful anymore.

    7. Re:Drop the marketing jargon for a minute! by Anonymous Coward · · Score: 0

      I wanted to know if with Cygwin, I could interact with the Windows environment, by doing the following for example.

      cd C:\Documents and Settings\Myname\My documents
      ls | grep 'term'
    8. Re:Drop the marketing jargon for a minute! by cecil_turtle · · Score: 1

      Ships with every Windows post 2000, I think.

      XP Pro only, not on XP Home:

      >taskkill /?
      'taskkill' is not recognized as an internal or external command,
      operable program or batch file.
    9. Re:Drop the marketing jargon for a minute! by Anonymous Coward · · Score: 0

      There's a reason we're not using some variant of the python interactive console as the shell. First, not everything is written in python. Second, changing the semantics from a simple file-based one to a intricate let's-pass-around-objects one is counterproductive in a shell environment when you have a thousand different programs that can interface with each other.

      You're getting to the heart of the matter. The unix shell has a major problem: legacy. People are trained on the existing tools, and refuse to move on to better systems as they are introduced. Instead they stick with an ugly system where there is little standardization of what output is generated, what flags are accepted, what configuration file formats are used. MSH doesn't suffer from that, because it is based on .NET, which is language and format agnostic. As long as your tool is .NET-based, integrating it with MSH will be easy.

    10. Re:Drop the marketing jargon for a minute! by pilkul · · Score: 1
      My biggest problem with the Windows command-line tools is that the documentation is terrible and they don't necessarily come with standard out-of-the-box Windows installations. So although I've heard you can do every administration task on the command line, I've no idea how. (By the way, this is a pet peeve of mine: people complain about Linux manpages but for some reason it's rarely mentioned how godawful the Captain-Obvious Microsoft documentation is. I've been using Windows since 3.1 and I've never --- not once --- been helped in any way by Microsoft help files.)

      If you or anybody else could point me to decent documentation on the Windows command line, I'd appreciate it.

    11. Re:Drop the marketing jargon for a minute! by cecil_turtle · · Score: 1
      Sort of, it looks like you can mount Windows drives/directories into cygwin. By default your C: drive should be under /cygdrive/c, after which you can do as you propose.
      Greg@DFZMRL51 ~
      $ cd "/cygdrive/c/Documents and Settings/Greg/My Documents"

      Greg@DFZMRL51 /cygdrive/c/Documents and Settings/Greg/My Documents
      $ ls | grep "My "
      My BZFlag Files
      My Downloads
      My Music
      My PSP8 Files
      My Pictures
      My Skype Pictures
      My Videos
      My eBooks
      Pocket_PC My Documents
    12. Re:Drop the marketing jargon for a minute! by JebusIsLord · · Score: 1

      I agree. Actually i'm rather wondering what MSH is going to provide that WSH doesn't.

      --
      Jeremy
    13. Re:Drop the marketing jargon for a minute! by Gorath99 · · Score: 1

      More .NET integration, piping objects instead of text only and improved tab-completion are some of the things I'm hearing. Basically giving you the option to spend less time in your favorite script editor and more in the shell.

      Sounds spiffy to me :-)

    14. Re:Drop the marketing jargon for a minute! by mattyrobinson69 · · Score: 1

      my guess as to the name of taskkill instead of kill is that in vb5, kill is the name of the 'delete file' function, strangely. why? i dont know either.

    15. Re:Drop the marketing jargon for a minute! by mattyrobinson69 · · Score: 1

      whats wrong with something like dcop for controlling processes in the shell?

      dcop amarok player play

      tells amarok to play a song, dcop's shithot and can be used in bash scripts.

    16. Re:Drop the marketing jargon for a minute! by value_added · · Score: 1

      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.

      You heard wrong and most of what you wrote is somewhere between vaguely misinformed and deluded.

      There is an almost infinite list of Things You Can't Do on the Command-Line. If such a list existed, it would be called Unix.

      But before you cry foul, allow me to cite off the top of my head a small list of perfectly ordinary if not mundane tasks that can't be accomplished without using a GUI: manage hardware or access hardware information; monitor basic system status; make changes to environmental variables; perform backups or restore files (yes, the ntbackup GUI runs even when the job is scripted); check or send email; change settings (unless your settings are in win.ini and not the registry); monitor or manage event logs; set user rights; read documentation (compiled html!); download, install or otherwise configure any program; manage Windows Update. And we're still not doing any real work, yet.

      Not only can you *not* manage a local system with any degree of effectiveness, but also most definitely you cannot manage another system remotely with any measure of success.

      Windows was constructed around the registry, wizards, property sheets, and rebooting. That means pointing and clicking in graphical widows. Any tools that Microsoft thought necessary were made into mmc snap-ins. A very small subset of needed tools were written as gosh-honest-to-goodness command-line programs. The rest is comprised of DOS-type utilities, and miscellaneous rubbish like vbscript and an interface to rundll32. Hell, there's even a GUI provided to modify boot.ini, along with warnings against not using the GUI!

      I don't know what exactly makes cmd.exe anemic - it's perfectly fine, in my opinion ...It does name completion (command.com didn't), which is basically THE killer feature for me.

      Dear God! I'm not quite sure how to respond to that without going over 5000 words. However, I would be remiss if I didn't point that the above statements present an honest, albeit extremely low threshold against which to measure the value of cmd.exe. You do know that command-line completion is not enabled by default and requires a registry change?

      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

      No, there is definitely not a thousand things. In fact, there is not more than a few desperately needed things, leaving a grand canyon-sized gap to be filled with tidbits from Sysinternals (often wholesale rewrites of the crappy Microsoft version), or Perl, or perhaps a full Cygwin installation. For the sake of argument, and assuming a low-threshold of usefulness, perhaps you can enlighten me which of those thousand things allows me to do something like actually manage currently installed services (past the stopping and starting part). A hint: you can't.

      If one does need to administer a Windows system using nothing other than a terminal, one would have no choice but to install the handful of oddball utilitities provided in the Resource Kit (not installed by default), and then install Cygwin and the GNU toolset and possibly just about everything else typically available on systems which *can* be be effectively administered on the command-line. And while that may be a good solution, it is, regrettably, still one giant workaround for some of the deficiencies I've been going on about.

      As for Microsoft's Latest and Greatest, I have zero doubt that it will be interesting, if not useful, but it's laughable to suggest that Microsoft, or anyone else, for that matter, can reinvent t

    17. Re:Drop the marketing jargon for a minute! by spongman · · Score: 1
      sorry, but you whole post is pretty much an ignorant troll:
      manage hardware or access hardware information; monitor basic system status; make changes to environmental variables; perform backups or restore files (yes, the ntbackup GUI runs even when the job is scripted); check or send email; change settings (unless your settings are in win.ini and not the registry); monitor or manage event logs; set user rights; read documentation (compiled html!); download, install or otherwise configure any program; manage Windows Update.
      All of these can be done from the command line (except reading docs) and most of them can be done remotely.
      do know that command-line completion is not enabled by default and requires a registry change?
      it's been the default for about 4 years, where have you been?
      can enlighten me which of those thousand things allows me to do something like actually manage currently installed services (past the stopping and starting part).
      erm, how about sc.exe?

      man, you're batting a zero.

    18. Re:Drop the marketing jargon for a minute! by glitch23 · · Score: 0

      The NET command certainly is well-known and used for about a thousand things, notable starting and stopping services.

      That works as long as you know the name of the service, which for some stupid reason, is different than the registry name for the same service, which makes things more difficult.

      --
      this nation, under God, shall have a new birth of freedom. -- Lincoln, Gettysburg Address
    19. Re:Drop the marketing jargon for a minute! by moonbender · · Score: 1
      --
      Switch back to Slashdot's D1 system.
    20. Re:Drop the marketing jargon for a minute! by Anonymous Coward · · Score: 0

      nice, but you're also letting Apple off the hook. forever they have claimed intel processors were crap compared to what they were using... and who would have thought apple would have turned to *unix* 10 years prior to OS X?

      one will always find it easy to bash microsoft in a place filled with as much ignorance as slashdot. once upon a time there was a message in the bashing. now it is just a senseless meme. the people who originally spoke out against MS knew when to stop and they knew MS was not "evil" as well. to accept MS as evil you must also accept capitalism as such, and I really don't think many people are prepared to deal with that.

    21. Re:Drop the marketing jargon for a minute! by Zancarius · · Score: 1
      Actually, it's far easier to do the following:
      [gridlock-vi:home]$ cd c:
      [gridlock-vi:c]$ cd Documents\ and\ Settings/
      Or:
      [gridlock-vi:home]$ cd c:/Documents\ and\ Settings
      [gridlock-vi:Documents and Settings]$
      The only problem with the latter option is that directories spanning drive letter assignments cannot be tab-completed. However, it's generally a lot less typing than going through /cygdrive/*. You can actually cd to individual drive letters (this works for anything, CD- and DVD-ROM drives included: cd e:).
      --
      He who has no .plan has small finger. ~ Confucius on UNIX
    22. Re:Drop the marketing jargon for a minute! by Zancarius · · Score: 1
      Pointing the finger and crying troll doesn't mix well with the mostly ad hominem commentary. Explain how this line is an answer to value_added's rather pointful observations:

      All of these can be done from the command line (except reading docs) and most of them can be done remotely.


      What is the Windows CLI mail reader? How about changing Outlook's configuration on the fly with nothing more than the CLI? Granted, tools like netsh are fairly useful, but there is a limitation to the Windows' philosophy that everything should be GUI-first, CLI-second.

      it's been the default for about 4 years, where have you been?


      You do know how long Windows 98 was still in use after the release of Win2k--after the release of WinXP? Hell, you had to install DOSkey in order to have up-arrow-style command history! AFAIK, I don't remember command-line autocompletion being the default with Win2k (Pro, don't recall the default in server)--though I think it is the default in XP Pro. Being as I have tweakui installed, I can't remember whether it was or was not the default.

      Now that we have this sorted out, riddle me this: What is Windows' equivalent of top? No--put your mouse down! We're talking a text-mode top processes list that's updated automatically. Bonus points if you can find one--without installing Cygwin.
      --
      He who has no .plan has small finger. ~ Confucius on UNIX
  90. Meme of misuse of term 'meme' by screwthemoderators · · Score: 2, Insightful

    Firstly, you're name speaks volumes about old FUD. Secondly, although Unix might be getting steamrolled, Free Software un*x wasn't, isn't, and will never be. Thirdly, I think its a funny story whether you're a fan of unix or not. On topic, it sounds like MS had finally figure out that they have to work harder to undermine the un*x installation base- nothing else

  91. RTFA by EvanED · · Score: 1

    Monad works substantially differently than the Unix tools.

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

  93. shazbot! by yagu · · Score: 1

    (sorry, couldn't think of a better subject line).

    After reading the link, and the meta-links, I'm not surprised. And, I'm not overly impressed. It's an okay CLI they've put together (though when they start bragging on themselves, they would do well not to put a link to "sample" cmdlets, and have no samples on the referenced page.)

    The sample scripts are pretty lame, certainly easy examples to do quickly and more tersely even in the lowly Bourne Shell.

    I've posted about this development before, and I'll restate... I wonder why Microsoft would come out with their own "version" of scripting when other good examples exist, and more standard ones exist. And, why for heaven's sake would they build so much into the shell? Isn't the shell supposed to be just that? I know this is essentially a philosophical nit, but again, lots of shells derived and fairly faithful to the Bourne/Ksh standard exist, have evolved (for interactive enhancements) and serve well...

    Hmmmmmmmmm, maybe Microsoft is preparing to jettison MKS? (That would be a shame.)

  94. MOD PARENT SIDEWAYS by Anonymous Coward · · Score: 0

    +1i, snarky!

  95. Troll does not compute! by screwthemoderators · · Score: 1

    Please, since SCO, please type un*x or some other variation, not "Unix." Are you a big supporter of VMS? Z-OS? Os9? I think its clear where the accusation of bigotry is coming from. Would the story be more funny if D. Cutler made a similar criticism to an non-MS marketing dweeb? or problems with Apple's marketing reality? I think it would be exactly as funny, and maybe just as appropriate. I think you're thinned-skinned at best, more probably sold-out.

  96. Actually, they are by DigitlDud · · Score: 1

    One of the main goals of Longhorn is to require that any configuration in the UI has a CLI equivalent.

  97. Windows catching up? by NineNine · · Score: 1

    Sounds to me, like somebody (or a whole lot of somebody's in this thread) seem a bit too agitated over a single new product. I think it's very obvious what's going on here, but everybody's afraid to say it, lest they become less 'l33t' in the future. Windows is filling in the gaps. Quickly. W2K has incredible stability. Security it rapidly increasing. Add a good command line interface (they already do have a scripting language, but *nix zealots like to ignore that), and there's not a whole hell of a lot of reason left why somebody would subject themselves to any *nix on the desktop any more. and, the onyl real innovation that has been done anywhere near the *nix camp in the past to years has come out of Apple. In the immortal words of David Spade: Unix: buh-bye.

  98. I would have modded you up but I had to reply by cbreaker · · Score: 1, Insightful

    I wanted to expand on your comment about how MSH could prove to be fairly useless because there's going to be no standard userland tools to go with it.

    It's not just the normal userland tools that will be a setback. It's everything else, too.

    In a Unix-style system, almost everything is ASCII text based. While there's GUI interfaces for a lot of stuff now a days, most configuration, logging, etc are done with text. This makes a powerful shell the perfect companion to those applications - you can process the text and do whatever you want with things so incredibly easy.

    You can practically backup the entire configuration of a system to a floppy disk. A few .conf files and a standard system image, you've got your system back and running in minutes. This is just an example of how powerful the CLI is - and you don't have to be a career programmer to make extremely useful and powerful scripts.

    So, without the same methodology as a Unix system, a powerful CLI on windows will probably have minimal impact to the system at large. Hey, I'll be glad to have it as a standard feature, but it won't change my life.

    --
    - It's not the Macs I hate. It's Digg users. -
  99. Obviously... by DigitlDud · · Score: 1

    You never used the thing did you?

  100. WTF??? Wikipedia is down by qaxzar · · Score: 0, Offtopic

    Why is wikipedia down??? has that ever happened before?

    1. Re:WTF??? Wikipedia is down by qaxzar · · Score: 1

      correcction: all the wp's but the japanese one are down.

    2. Re:WTF??? Wikipedia is down by qaxzar · · Score: 1

      update: english has come back up, many others still down

    3. Re:WTF??? Wikipedia is down by rbarreira · · Score: 1
      --

      The AACS key is NOT 0xF606EEFD628B1CA427BEA93A9CA9773F
  101. Yes you can by DigitlDud · · Score: 2, Informative

    The entire .NET class library is exposed to MSH. And the class library almost entirely wraps all Win32's functionality. So yes, you can do anything. The design philosophy behind Longhorn is that any UI configuration must be exposed in the CLI. On and by the way, you get lossless JPEG rotation in Longhorn.

  102. Just an FYI... by Anonymous Coward · · Score: 0

    .
    .
    .
    . ... you fail it...

  103. See... by DigitlDud · · Score: 1

    I was waiting for someone to do this. Piping to awk is a HACK. You're parsing text and assuming the memory consumption is always the 8th column. Which it isn't always. Not having to parse text is one of the reasons MSH is so great.

    1. Re:See... by Eudial · · Score: 1

      I was waiting for someone to do this. Piping to awk is a HACK. You're parsing text and assuming the memory consumption is always the 8th column. Which it isn't always. Not having to parse text is one of the reasons MSH is so great.

      In everyday administration use i don't care if some obscure implementation doesen't put RSS in that column, why would that be of concern when the system I'm entering the command on does?

      --
      GAAH! MY PRINTER IS ON FIRE!!! PUT IT OUT! PUT IT OUT!
    2. Re:See... by ZorbaTHut · · Score: 2, Insightful

      When you update your installation and suddenly all your scripts break.

      Alternatively, when you keep having to add new data on the *end*, instead of next to the columns that it's logically related to.

      --
      Breaking Into the Industry - A development log about starting a game studio.
    3. Re:See... by geomon · · Score: 2, Funny

      When you update your installation and suddenly all your scripts break.

      Of course nothing ever breaks with a Windows update.

      --
      "Rocky Rococo, at your cervix!"
    4. Re:See... by ocelotbob · · Score: 1

      Here, pasting the results next to the columns it's logically related to. Trust me, Unix has assloads of text processing abilities. Use the shell for a while and you learn lots of nice little tricks and commands.

      --

      Marxism is the opiate of dumbasses

    5. Re:See... by LnxAddct · · Score: 1

      All of these folks are showing their ignorance of the whole point of scripting and integration. MSH is forcing developers to create their programs to work especially with MSH which will include writing extra code to see if it is being piped or if output should be directed to stdout. In unix, the developer doesnt need to care, nor does he need to know what or where the output is going. He just sends it out, if another program wants to do something with it, then it does, otherwise the user reads it or directs it into a file. This MSH is more or less an interactive .NET environment, you can do very similar things with much simpler syntax in unix using Ruby's (irb) or Python's interactive shells. The only advantage to objects is speed, but why are you scripting something if your looking for speed. Also, the only way that MSH can avoid making the developer do any extra steps is if it gives piped programs direct access to its classes which would be nuts. Unix scripting is extremely powerful and has been finely regrained over and over again for decades now. This MSH thing is nothing but a slight paradgim shift using a hack of an interactive scripting environment. This whole story is filled with nothing but microsoft lovers having no clue how powerful bash is or how to properly use it.
      Regards,
      Steve

    6. Re:See... by gromitcode · · Score: 1

      you don't seem to get the point, because you are parsing based on assumed position you are more prone to breakage. And guess what if you change the parameters passed into PS you get different column numbers. The MSH way takes it as an object and hence it doesn't matter whether MS add or remove 20 new columns or move the virtual memory column to position X instead of Y it will still work.

    7. Re:See... by DigitlDud · · Score: 1

      You don't write extra code for handling piped output or writing to the console. I don't understand what you're on about. MSH will figure out how to format your command's output by running reflection on its properties.

      The only advantage to objects is certainly not speed. Working with objects as opposed to text output has many advantages. It's much more elegant and intuitive. The command you pipe your output to doesn't even need to know what kind of object you're sending it. It can use .NET's reflection to discover what the Object's members are. The objects piped can expose methods which you can execute without using another command. The whole object-oriented concept in a shell opens up many possibilities.

      Also, the only way that MSH can avoid making the developer do any extra steps is if it gives piped programs direct access to its classes which would be nuts.

      I'm sorry but I have no idea what you're talking about. MSH has many unique features besides object piping. You can find out about them by reading the DOCUMENTATION.

    8. Re:See... by LnxAddct · · Score: 1

      You make some exellent points and do a great job of pointing out my ignorance ;) Regardless, shell scripting is ideally for system administrators, not for programmers (despite the fact that they often use it). A system administrator should not have to learn about object oriented programming or .Net just to automate administration of the system. In bash, its more or less "Run these commands in this order, oh yea you can also make this command use this other command's output for it's input. If you want you can add some logic and loops too if you can wrap your mind around those concepts" and that will cover 95% of scripts. The system administrator needs to learn minimal programming skills at best (no more then a BASIC programmer in most cases). With this Monad stuff, it seems to me that they are requiring the system administrator to learn a heck of alot more, in fact, more or less becoming a rudimentary .Net programmer. Also, scripts are typically meant to be small and maintainable. If you know my posting history then you know that I'm a huge fan of Java and C++, but the complexity of their language syntax is not necessary for small scale maintainence of the type of scripts most admin I've seen write. It just seems to me that Microsoft is forcing .Net into places it doesn't belong.
      Regards,
      Steve

    9. Re:See... by geomon · · Score: 1

      you don't seem to get the point,

      I got the point: my comment was meant to be a JOKE.

      --
      "Rocky Rococo, at your cervix!"
  104. the *real* screenshot by Petronius · · Score: 1


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

    I see you are trying to run MSH.exe
    Are you sure?

    [Abort, Retry, Fail]?

    --
    there's no place like ~
    1. Re:the *real* screenshot by Anonymous Coward · · Score: 0

      Nothing like a bit of FUD is there?

  105. A reason why *nix isn't ready for the desktop. by Vicsun · · Score: 1

    But your example is oh so less user-friendly.

  106. Usability vs. Learning Curve by BlurredWeasel · · Score: 1

    Learning Curve: The time it takes to get to various points of being able to use a system (ie, can you change directories, can you do a ps, can you do a ps | grep | awk > file)

    Ease of Use: How quickly can you do things once you've been trained. This is the more important thing in my opinion in this case. Since the command line won't be used more than a few times by typical users, it is very much an admin/power tool. Things like ps is preferable to 'get-process' once you know whats going on.

    Different tools require a different balance between ease of use and usability. I think shells should tilt towards usability rather than an easy learning curve.

  107. Re: No Thanks (not UNIX, VMS!) by Prothonotar · · Score: 2, Insightful

    Having tried to use the VMS shell once, if Monad is based on VMS, then Monad and Microsoft deserve each other. :)

    --
    "Every man is a mob, a chain gang of idiots." - Jonathan Nolan, Memento Mori
  108. Re:That's all well and good by moonbender · · Score: 2, Insightful

    Why, exactly? There are plenty of alternatives for scripting - both by Microsoft (WSH) and of course there's also Python, Perl and everything else. And for interactive usage, the existing cmd.exe is sufficient, to me anyway. Once I figured out how to enable auto-complete I didn't really miss anything from the Unix shells. Hm.

    --
    Switch back to Slashdot's D1 system.
  109. This is (probably) not the way to go by spockvariant · · Score: 1

    One might argue that most innovation in software engineering, program analysis and verification in the past decade has been realized in the OO/formal semantics community. So for instance, since this exciting piece of work is implemented in a framework of OO-like interfaces, it is inamenable to crude pipe-based scripting languages. There has long been a debate between academics and designers of popular scripting languages like perl on which way to go (eg. http://www.ai.mit.edu/projects/dynlangs/ll1/). Although no one side has really won, one conclusion that stands is that scripting defines its own programming paradigm which should not be confused with anything else that comes close. Scripting languages MUST facilitate quick and dirty solutions that just work, or they're not scripting languages anymore. Usually, the more loaded a language gets with type information and rigid control constructs, the less capable it gets of letting you produce results without having to design and debug much.

    1. Re:This is (probably) not the way to go by starfishsystems · · Score: 1
      Agreed.

      And when a problem is suited to scripting, it's also simple to implement over distributed systems. True scripting languages are inherently serialized, hence there is no issue with passing objects between systems.

      You can't do everything this way, but there are many useful cases when you can, remote system management being one example. Then what you don't want is to find yourself stuck with yet another bloated vendor language that gets in the way of clean interoperability.

      --
      Parity: What to do when the weekend comes.
  110. Re:Or you could just download the release-quality by cahiha · · Score: 1

    Instead of building scrips through Perl or Python or whatever you use this is going to be centered around building "scripts" in .NET.

    Yes, and that's exactly why bash is beter. If you want something "between" Perl and bash, use Tcl/Tk.

  111. In Other News by Burz · · Score: 0, Redundant

    The GNU Project announces plens to merge KParts into the Bourne-Again Shell. :-D

  112. Torrent for MSH/Monad 32 bit version by mr.henry · · Score: 1
  113. The monad experience... by Zancarius · · Score: 1
    From your Wikipedia link:

    In the writings of the philosopher Gottfried Leibniz, monads are atomistic mental objects which experience the world from a particular point of view.


    Seriously--can anyone read that description and not laugh, given the context of previous posts...?

    "My monads experience the world from a particular point of view. It's usually very dark, of course, but sometimes they can come to light."
    --
    He who has no .plan has small finger. ~ Confucius on UNIX
  114. Re:Here's a Screenshot - FAKE by Anonymous Coward · · Score: 0

    The other screenshot is a fake. heres a real one.

    ----

    Microsoft Command Shell
    Copyright (C) 2005 Microsoft Corporation. All rights reserved.

    MSH> cd 'C:\Documents and Settings\All Users'
    MSH> ls

    Directory: FileSystem::C:\Documents and Settings\All Users

    Mode LastWriteTime Length Name
    ---- ------------- ------ ----
    -a--- Apr 17 23:25 262144 ntuser.dat
    d---- May 29 12:49 Desktop
    d-r-- Jun 18 10:37 Documents
    d---- Apr 17 20:54 Favorites
    d-r-- May 11 11:50 Start Menu

    MSH> ls | group-object Mode

    Count Name Group
    ----- ---- -----
    1 -a--- {ntuser.dat}
    2 d---- {Desktop, Favorites}
    2 d-r-- {Documents, Start Menu}

  115. usability by cahiha · · Score: 1

    Short, cryptic names hinder usablity by greatly increasing the learning curve.

    Just because you think so doesn't make it true.

    1. Re:usability by The+Wooden+Badger · · Score: 1

      Yeah, I'd remember the short cryptic names better, so the short names are absolutely better. Deal with it.

      --
      Heroscape, it's like legos combined with anachronistic wargames.
    2. Re:usability by cahiha · · Score: 1

      Yeah, I'd remember the short cryptic names better, so the short names are absolutely better.

      You might well remember the short names better. Until somebody does the experiment, we don't know.

      Deal with it.

      Stop presenting your preconceived notions as facts. You probably also believe the earth is flat because, hey, it's so obvious to you.

    3. Re:usability by The+Wooden+Badger · · Score: 1

      Try this: Read the parent and then reread my post. Think about it for a while, and I'll wonder how your post has a score of 2.

      --
      Heroscape, it's like legos combined with anachronistic wargames.
  116. Rewrite What? by Anonymous Coward · · Score: 0

    1) What's there to port/rewrite and why? It's an administration shell - not new OS.
    2) Writing for Monad is piece of cake - since it can use reflection (.Net) writing new commands for it is a breeze - tens of times simpler than for any shells I've ever seen. My guess is that just few days after official release - you'll start seeing more and more commands for MSH.

  117. Interesting security implications by M4tth3wV · · Score: 1

    Should be interesting to see what security features are builtin to this shell....

  118. vi by obdulio · · Score: 1

    will it support vi commands, like ksh?

    vi was designed to work over very slow connections.

    sometimes, I need to work over very slow modem connections, using vi commands in a Unix shell is the only way to work. I mean a 9600 kbps modem dialing to a customer in another country.

    --
    PENAROL: Seras eterno como el tiempo y floreceras en cada primavera.
  119. No, it doesn't by Anonymous Coward · · Score: 0

    This is a lot more than just another shell. If you won't RTFA, read a livejournal posting of mine where I came up with the same idea about a month before hearing about Monad. It has pictures describing how it works.

  120. Mods are on acid again by Burz · · Score: 1

    The GNU Project announces plens to merge KParts into the Bourne-Again Shell. :-D

    -1 Redundant?

    There is no other suggestion in the entire discussion that bash could merge with KParts.

  121. Only a 'g' away by batura · · Score: 1

    Did anyone else nearly choke laughing on the word Monad?

  122. Primary source by Kaseijin · · Score: 1

    Yes, an unsourced claim on Wikipedia must be accurate, no matter how little sense it makes.

  123. About 1000 years? Good for 20,000 years! by Anonymous Coward · · Score: 0

    Bear in mind that in Vernor Vinge's 'A Deepness in the Sky' it's in passing that all their systems run on Unix timementioned http://en.wikipedia.org/wiki/A_Deepness_in_the_Sky

    1. Re: About 1000 years? Good for 20,000 years! by Anonymous Coward · · Score: 0

      make that "mentioned in passing". I drank too much of the fizzly water tonight...

  124. No it doesn't by jesterzog · · Score: 1

    Because the ability to use a CLI demonstrates a true understanding of what's happening on the computer.

    No it doesn't. You're confusing an expert command-line interface with every command line interface.

    It's also possible to design a beginner's command line interface, which wouldn't necessarily imply anything of the sort.

  125. Nice idea, fifteen years too late by puzzled · · Score: 1


    Microsoft has needed a decent command line since Windows 1.0 and they're just getting around to it now? They were OK in begin graphical and sticking to their guns, actually starting to produce something like this is admitting that they screwed up bigtime ... a trend like this could in in a text mode Windows that only sucks a little.

    --
    I am very easy to get along with, but I don't have time to waste being nice to people who are being stupid. -Theo
  126. Microsoft release version == pre-pre-alpha by Futurepower(R) · · Score: 1


    I agree, Microsoft's command-line interface will be like IE. The first release version of a Microsoft program is, in my opinion, more like a pre-pre-alpha than a version that should be released.

    Internet Explorer is following this pattern exactly. By version 7, IE will be renamed to make it sound completely new, perhaps, and will actually be Microsoft's first relatively bug-free browser. Version 7.0 of Microsoft Internet Explorer should actually be called version 1.0.

    Perhaps 2 years ago I was talking with some top-level Microsoft technical support representatives. I gave them a list of 12 ways Microsoft's command line interface (which everyone calls DOS) did not fully support a 32-bit OS. They agreed and seemed embarrassed.

    I also sent a message to a group inside Microsoft about this. I said that the Linux and BSD command-line processors were relatively bug-free, and had far more features. Surprisingly, I got a response indicating that they too thought that Windows should not have a primitive toy command-line interface like DOS.

    Apparently having a toy command-line interface has been causing some discomfort inside Microsoft.

    Expect Microsoft's new command-line interface to follow the same pattern. It will be very, very buggy. Maybe the U.S. government's spy agencies will direct Microsoft to include security vulnerabilities. In any case, if history is any guide, the new command-line interface will be quite usable about 3 years after release, and by about version 7 will be fairly bug-free and feature-complete.

    (Of course, Microsoft Word has not followed this pattern. Even after many versions, it is still extremely quirky. My understanding is that the code in Word is such an extreme mess that there is no corporate will to fix it.)

    Want an example of DOS not fully supporting a 32-bit OS? Try this:

    SUBST R: C:\

    This assigns the drive letter R: to the root folder of the C: drive. This kind of substitution is often very valuable in taking some of the drudgery out of corporate operations.

    However, that command also destroys the operation of the Recycle bin. It seems to be reversible, however, so there appears to be no harm in trying it, which I have done on several computers with no ill effects that I was able to detect.

    To undo the command, enter:

    SUBST R: /d

    1. Re:Microsoft release version == pre-pre-alpha by X0563511 · · Score: 1

      No, the origional post was in the correct spot. At least it seemes like it to me :D

      --
      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...
  127. Microsoft release version == pre-pre-alpha by Futurepower(R) · · Score: 1


    After all these years, Slashdot is still quite buggy. It posted my comment under the wrong parent, so I posting it again here, where it will make sense. My comment:

    I agree, Microsoft's command-line interface will be like IE. The first release version of a Microsoft program is, in my opinion, more like a pre-pre-alpha than a version that should be released.

    Internet Explorer is following this pattern exactly. By version 7, IE will be renamed to make it sound completely new, perhaps, and will actually be Microsoft's first relatively bug-free browser. Version 7.0 of Microsoft Internet Explorer should actually be called version 1.0.

    Perhaps 2 years ago I was talking with some top-level Microsoft technical support representatives. I gave them a list of 12 ways Microsoft's command line interface (which everyone calls DOS) did not fully support a 32-bit OS. They agreed and seemed embarrassed.

    I also sent a message to a group inside Microsoft about this. I said that the Linux and BSD command-line processors were relatively bug-free, and had far more features. Surprisingly, I got a response indicating that they too thought that Windows should not have a primitive toy command-line interface like DOS.

    Apparently having a toy command-line interface has been causing some discomfort inside Microsoft.

    Expect Microsoft's new command-line interface to follow the same pattern. It will be very, very buggy. Maybe the U.S. government's spy agencies will direct Microsoft to include security vulnerabilities. In any case, if history is any guide, the new command-line interface will be quite usable about 3 years after release, and by about version 7 will be fairly bug-free and feature-complete.

    (Of course, Microsoft Word has not followed this pattern. Even after many versions, it is still extremely quirky. My understanding is that the code in Word is such an extreme mess that there is no corporate will to fix it.)

    Want an example of DOS not fully supporting a 32-bit OS? Try this:

    SUBST R: C:\

    This assigns the drive letter R: to the root folder of the C: drive. This kind of substitution is often very valuable in taking some of the drudgery out of corporate operations.

    However, that command also destroys the operation of the Recycle bin. It seems to be reversible, however, so there appears to be no harm in trying it, which I have done on several computers with no ill effects that I was able to detect.

    To undo the command, enter:

    SUBST R: /d

  128. Re: No Thanks (not UNIX, VMS!) by aaamr · · Score: 1

    Ditto for OS/400. Ugh.

  129. REXX by os2fan · · Score: 1
    One can also use the OS/2 paradigm on much of the Windows stuff, like I do. There are even DLL files, like Jeff Glatt's "filerexx.dll" that allow you to hook into the shell and registry.

    The main trouble is that a lot of the CLI interfaces are not documented. Even going into the program to find switches for the program is a bit of a nuisance.

    You can play around with sendkeys() or keystack to sent keystrokes to a command window, but even this interface might not be as robust as one hopes. This is the sort of interface they wanted to move people off. Lotus for DOS programmed using /FS~ to menu-file-save and press enter.

    The OS/2 and Windows implementations of pipes is itself poor. I had pipes run, and then close the window.

    The documentation on how to pass parameters to commands is abysmal. Unless you know the magic of putting a * after the association in registry, you won't be able to pass parameters to external scripts (eg myfile.rex 2+3)

    --
    OS/2 - because choice is a terrible thing to waste.
  130. Gonad? by Anonymous Coward · · Score: 0

    So when are the Gnome people going to port it to Linux and call it Gonad?

    1. Re:Gonad? by chawly · · Score: 1

      Don't really mind who does it. Gnome or just a GPL version. I think I read a suggestion on /. regarding a GPL licensed version called Gonad. The splash screen was to announce "GONAD! Microsoft, don't you wish you had one ?!!" Don't care who does the work, but I think the splash screen should be kept. Complementary copy to Bill. Just my idea .. my deux centimes as you chaps say.

      --
      How many beans make five, anyhow ? ... Charles Walmsley
  131. Just a part of the system by Hal+XP · · Score: 1

    Monad is likely to play a different role in Windows than *sh and friends in the *n*x world. No matter how horrible or wonderful Monad (rhymes with gonad) turns out to be, it will just be an accessory. The future of Windows and Redmond doesn't hinge on the success of Monad. But they better come up with something prettier than OSX before 2007. (The server market is pretty much lost to *n*x whether of the BSD, OSX, GNU or Solaris variety.)

    --
    I'm a sci-fi vegan: I don't want the aliens to think we have as much right to live as the fried chickens we eat.
  132. Hooray! by Just-some-person · · Score: 0

    Hooray for taking others' ideas, putting your name on them and selling them!

  133. A few very handy things I would like to see by chiok · · Score: 2, Interesting
    Is there a way to get a 4DOS style history or something like bash's history-search-backward & history-search-forward? That might be a deal breaker for me if not.

    Also, the 4DOS wildcard rename feature has unfortunately not been adopted.

    What no tabs?!?

  134. Building a python shell by Peter+Eckersley · · Score: 1

    That would be hard, MSH leverages .NET quite extensively. You might see a Mono Shell, or a Python Shell using the same concepts though.

    I tried writing a object-oriented python shell a few years back. There are certainly a great many improvements to be had over bash or zsh. Nice tab completion was difficult to implement though, because parsing incomplete python commands is tricky and because other strategies (such as building hypothetical constructions and prodding them) are made difficult by python's highly dynamic nature...

  135. I heard... by SQLz · · Score: 1

    they put a patent in for command line completion with one special advatage, command line completion while...on the Internet!

  136. Cygwin != Windows by bXTr · · Score: 1

    Bash and Korn shell do NOT run on Windows; they run under Cygwin and U/WIN, respectively. In all honesty, Monad doesn't run on Windows but on .NET. The only shells that actually run on Windows are COMMAND.COM and CMD.EXE. If you read the available documentation on CMD.EXE, you'd see that it actually can do a lot of the things the Unix shells can. The things it can't do are due to the obvious differences between Unix and Windows.

    --
    It's a very dark ride.
    1. Re:Cygwin != Windows by torpor · · Score: 1

      Bash and Korn shell do NOT run on Windows;

      look, its running on my Windows PC, therefore: it runs on Windows. It doesn't matter that it 'needs' CYGWIN.DLL, because: THIS IS A WINDOWS THING.

      --
      ; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
  137. You mean U/WIN by bXTr · · Score: 1

    The only official Korn shell, ksh93, for Windows is from U/WIN. SFU (as opposed to STFU) comes with pdksh; a clone of ksh88 and absolutely NOT the official ksh.

    --
    It's a very dark ride.
    1. Re:You mean U/WIN by Nimrangul · · Score: 1
      So just because it is not the AT&T ksh it is suddenly not the ksh that Microsoft puts out for Windows?

      Damn, I better tell the OpenBSD people that their sh isn't their official sh version! Cause hey, it's ksh, no wait, not even that! ksh isn't the ksh they release because it's pdksh! Hell, it's not even pdksh anymore, it's been patched to add additional functionality and repair bugs, so it's not even their pdksh release!

      Microsoft releases it and calls it ksh bXTr, therefore it is the official release from Microsoft. It's the one that Microsoft says is for Windows, last I checked they were the ones making the operating system.

      --
      I'm sick of following my dreams - I'm just going to ask them where they're going and hook up with them later.
  138. I resent that by infonography · · Score: 1

    if anything I am bigoted against know-nothing jerks who stand on flimsy data. I am writing this from a windows box.

    --
    Sorry about the writing. Robot fingers, you know? Cliff Steele in DOOM PATROL #23
  139. Huh? by KwKSilver · · Score: 1

    Most Linux GUI software isn't usable from the command line

    Oh really? I started this browser (Galeon)--from a terminal shell, e.g Konsole, on KDE.

    --
    If you want your life to be different, live it differently.
    1. Re:Huh? by brpr · · Score: 1

      Oh really? I started this browser (Galeon)--from a terminal shell, e.g Konsole, on KDE.

      1) You can start GUI apps from the terminal in Windows. 2) You're completely missing the point. Galeon does not have any browsing functionality which is not dependant on a GUI interface; you can start it from a command line but you can't do anything else with it.

      --
      Freedom is not increased by mere diminuation of government. Anarchy is freedom for the strong and slavery for the weak.
    2. Re:Huh? by TheWormThatFlies · · Score: 1

      2) You're completely missing the point. Galeon does not have any browsing functionality which is not dependant on a GUI interface; you can start it from a command line but you can't do anything else with it.

      On the contrary; there are quite a few things that you can do with Galeon from the command line. You can open a link in a new window, in a new tab in an existing window (with the option of mot raising the tab), toggle full-screen display of currently open galeon windows, add a bookmark or open a session file.

      Obviously you can't actually view webpages in Galeon without a GUI, because what Galeon is is a GUI web browser. However, it's integrated with the command line as well as an app which displays multimedia in a GUI can be, and this functionality makes it more useful to me. "galeon -n --noraise %s" is my system-wide browser command. It lets me unobtrusively open links from anywhere in the background of my open Galeon window.

      More pertinent to the original point, though, is that in Linux many GUI apps are just skins for established, fully functional CLI applications. You can use the GUI if you want, but you can also just use the bare command line app if that's what you prefer. I don't think that there is any functionality in Linux which can only be accessed through a GUI (perhaps the configuration of some GUI app preferences - but usually those are stored in editable configuration files).

    3. Re:Huh? by brpr · · Score: 1

      Obviously you can't actually view webpages in Galeon without a GUI,

      Yes, that is the point you were missing. Come on, we're talking about apps with a significant degree of command line functionality here. Not just apps which can be launched from a command line (which includes all Windows apps).

      As I pointed out in my original post, the access to .NET libraries will go along way to make up for the lack of command line utlities in Windows.

      --
      Freedom is not increased by mere diminuation of government. Anarchy is freedom for the strong and slavery for the weak.
    4. Re:Huh? by TheWormThatFlies · · Score: 1

      Obviously you can't actually view webpages in Galeon without a GUI,

      Yes, that is the point you were missing. Come on, we're talking about apps with a significant degree of command line functionality here. Not just apps which can be launched from a command line (which includes all Windows apps).

      I think you missed what I just said. Galeon has command-line functionality beyond "being launchable from the command line", which is obviously a trivial criterion satisfied by any application at all. I named specific commands which can be issued to Galeon from the command line.

      It is possible that the great-great-grandparent poster was completely missing this, and was actually claiming that "being launchable from the command line" counts as integration. Nevertheless, the application he chose for his example is actually integrated with the command line quite well for a GUI browser. So are many other GUI apps in Linux - you can often enter a command in a terminal to have something happen within a GUI interface. This does not eliminate the need for the GUI; it supplements the GUI.

      As far as I remember, though, the original point was that in Linux you can perform just about any task from the command line (that is, that both command line and GUI apps exist for any task), not that you can use any specific GUI app from the command line (a proposition which doesn't make much sense).

      I can confirm that this is true. I can perform administrative tasks from the command line. I can edit text from the command line. I can browse the web and use email from the command line. I don't actually do the last two very often, but the option is there, and is very useful if you're working on a server which has no GUI installed. And the most important thing is that the command line is a fully-featured useful tool, and not just a neglected and ignored fallback mechanism.

      I'm not claiming that you can't achieve the same thing in Windows, since I haven't used Windows enough to be familiar with it, but from my limited experience I don't think the Windows interface encourages that kind of use - and I've never seen a Windows sysadmin use anything except a GUI to do things.

      This new shell may improve things, but not by very much if it doesn't come with command line utilities. Sure, if there are libraries which allow script-writers to access the internals of the system, it will be possible for them to write scripts to duplicate the functionality of those utilities, but they will still have to write them.

      I suspect that what will end up happening is widespread adoption of common scripts, which will become the de facto standard utilities - but it really should be Microsoft's job to write them in the first place. I consider system utilities to be core functionality of any complete operating system. Offering an environment for running them, but leaving the user to reinvent the wheel by himself, seems a half-hearted effort, and an inferior solution compared to, for example, Cygwin.

  140. That's retarded, and you know it. by SmittyTheBold · · Score: 1

    Okay, so what should we be learning from the fact that "process" is abbreviated "ps?" Apparently, the rule when naming UNIX commands is to take the first and last letters.

    Okay, so directory list, should be...dt? Okay, we'll assume we just want "list" so then the command would be..."lt." Oh, I guess it's first and second-to-last letters. That works for both situations. Now, let's use an editor. "eo" does nothing for me. Hmm, my learning device must be broken somehow.

    On the other hand, the MSH commands follow a predictable pattern: to get data, you use a command starting with "get-" followed by what it is you want to get. Get-content. Get-process.

    Get-a-grip. Next time you claim that learning by wrote equals intuitive knowledge, I reserve the right to kick you in the balls.

    --
    ± 29 dB
    1. Re:That's retarded, and you know it. by aminorex · · Score: 1

      is it get-data or get-content? wtf is "content"? how about get-text, what does that do? get-content from where? there's nothing intuitive about it. are there aliases in the locale for the majority of the users, the ones who don't speak english? why should i "get" things instead of "show", or "list", or "examine". why are is it a "process" and not a "job" or "task".

      none of this is "intuitive".

      --
      -I like my women like I like my tea: green-
    2. Re:That's retarded, and you know it. by SmittyTheBold · · Score: 1

      I never said it was intuitive. I said it's more logically and predictably laid-out that the UNIX Way of Life. Yes, somebody who's unfamiliar with the command set will be confused at first. THe thing is, once you know one of the commands, it becomes quite a bit easier to predict the name of, and how to use, other commands.

      This in stark contrast to UNIX commands where the names are chosen based on varying rules, some commands accept regexp input while others have their own special formatting (or require that you use grep with them), and it's in general a much longer learning curve.

      In short, I agree. Intuitive is the wrong word. (In addition, the way I phrased is made it look like I was calling the MS way intuitive - that's not my intention.) THey're both artificial constructs that the user has to learn to control. My argument is that while the UNIX way offers shorter command names once you're intimately familiar with the command set, it may save oyu a little typing. On the other hand, the MSH command set should be easier to use while you're still learning how to use it.

      --
      ± 29 dB
  141. Win32 Perl no longer in Resource Kits... by ManyLostPackets · · Score: 1

    Funny how no post 2000 OS resource kit has Perl anymore...

  142. Der. by shift82 · · Score: 0

    "Dir" makes a dumb noise in my head. Dehr. Dehr. Dehr. It annoys me.

  143. It jumped around. by Futurepower(R) · · Score: 1


    It's weird. It jumped around. It was in a different position before.

  144. Want a command language for Windows? by Futurepower(R) · · Score: 1


    Want a command language for Windows? Try the free, open source AutoIt, which is amazingly complete and well-developed. AutoIt comes with an autocompletion IDE that automatically displays function usage information. The version that includes the IDE installs easily. AutoIt also has a compiler, which is also free. See AutoIt on Sourceforge.

    Want Hotkey macros? Try the related free program, AutoHotKey.

    Both are excellent.

    They both are here now, with no Microsoft grief.

  145. The reason is.... by TransEurope · · Score: 1

    > 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) ?
    ...that Windows and his producers are absolutely unsexy and less of style. They have no glory history, no real geeks and hackers as heros. All they own is the need for money and an ugly guy with stupid visions.

  146. Re:strings for piping by Anonymous Coward · · Score: 0

    And what is MSH "piping" around that isn't bytes?

    Oh, now I know... They must have taken decades building it, and it's really built for Intel 4004 processors, so it's half-byte strings.

  147. Cut and Paste Re:This is fantastic news. by Anonymous Coward · · Score: 0

    Have you tried cutting and pasting in Office / Outlook 2003? It used to work, but on my system at work it's badly broken.

    In every other way though - Windows is becoming so much like Linux. It even has text based config files (remember all the sneering Windows zealots used to give us on that one) and the concept of home directories.

  148. Re:strings for piping by eurleif · · Score: 1

    Bytes that are guaranteed to be formatted in a certain way.

  149. .Net and viruses. by solomonrex · · Score: 1

    Don't just say there will be viruses, when M$ is so acutely aware of the problem. With it being on top of .Net, what makes you think appropriate security won't be implemented? .Net was built with networking and security in mind, and so is Longhorn. Plus, I doubt that the monad shell will be implemented by default for home users - why would they need it?

    Can you explain how this will be a boon for virus writers?

    1. Re:.Net and viruses. by Ucklak · · Score: 1

      It's the nature of the beast. Not the Microsoft beast but script writing.

      I'll say that MS's Server 2003 is a decent product and I 'hope' that they really do have security as a concern but I don't buy it. The fact that they will offer a paid for virus subscription service proves it.

      Script writers will utilize Monad for what it is supposed to do. Viruses will be written on top of it but may not be able to exist in the wild like all of the Linux and OSX Viruses.
      If all the Viruses that will exist for Monad are concept only, than I'll give MS a pat on the back and say 'good job'. I did say that Server 2003 is a decent product.

      The other thing about Monad is that if Monad existed years ago, I proably wouldn't have jumped the MS ship. Professionally I won't mind trying it but personally MS gives me a bad taste.

      --
      if you steal from one source, that is plagiarism, if you steal from many, well, that's just research.
  150. Re:Monad REALLY is comming by tfl · · Score: 1
    At present, Monad-MSH is planned to be part of E12 and WinFX SDK - both of which should RTM next summer, at/around Longhorn time. MSH _will_ run _on_ Longhorn just fine (just like .NET Framework 1.1 runs on XP). But it may not be distributed within the box. Hopefully, this is an anomoly that will get sorted out once Longhorn Beta 1 ships this summer.

    In the meantime, if you're a Windows ADMIN, I'd recommend you get the beta now and start playing with it - it has value today, let alone on a years time!

  151. SHUT UP!!!! by Anonymous Coward · · Score: 0

    SHUT UP! Shut the fuck up! If I see ONE MORE post where some fuckhead says "Bzzzt!" I swear that I am going up the clocktower. You stupid father-fucking cunt.

  152. 80 characters? by permanentE · · Score: 1

    If this shell lets me widen it to more than 80 characters I'll be happy. Nothing, not even cygwin, let's me do that on any Windows.

    --
    What was the last law that benefited people but not corporations?
    1. Re: 80 characters? by hackerssidekick · · Score: 1

      Right click title bar -> properties -> layout tab -> Window Size: Width, and while you're there also Screen Buffer Size: Width

  153. Yup - "%*" is all command-line parameters. by CRConrad · · Score: 1

    Come on, give them SOME credit -- even cmd.exe can't be so brain-dead as not to get THAT simple thing!

    You, OTOH, apparenly are -- how the heck could you NOT figure out that it would be "%*"? (It's freaking obvious, the asterisk wildcard for "all of them". In comparison, the Unix shells' @ is pretty damn non-intuitive. "At?!? At where, and why???")

    --

    Christian R. Conrad
    mail me at iki.fi ; same user ID as here
    1. Re:Yup - "%*" is all command-line parameters. by mi · · Score: 1
      Hey, I'm just looking at the cmd-scripts our Windows developers are using. The try to simulate "$@" with %1 %2 %3 %4 %5 %6 %7 %9 (because no one will ever pass more than 9 arguments, right?).
      In comparison, the Unix shells' @ is pretty damn non-intuitive

      Unix shells have $* as well, but there are subtle differences in how these two (* and @) handle arguments, which have blank spaces inside them...

      --
      In Soviet Washington the swamp drains you.
  154. OK, so your Windows developers are morons... by CRConrad · · Score: 1

    ...and you now know more than they do. Please tell them how to do it right.

    In their defense, though: The "no one will ever pass more than 9 arguments" idiocy seems to be alive and well in Unix shells, too.

    $cat silly_test.sh
    #!/bin/ksh
    <==[Tested it with "sh" and "csh" too]
    echo $@
    echo $0 $1 $2 $3 $4 $5 $6 $7 $8 $9 $10 $11 $12 $13
    $silly_test.sh A B C D E F G H J K L M N O
    A B C D E F G H J K L M N O
    ./silly_test.sh A B C D E F G H J A0 A1 A2 A3
    $


    So... All software sucks, it seems.

    --

    Christian R. Conrad
    mail me at iki.fi ; same user ID as here
    1. Re:OK, so your Windows developers are morons... by mi · · Score: 1

      Try ${11}... What is the equivalent for Windows? And will %11 work to concatenate %1 with digit 1?

      --
      In Soviet Washington the swamp drains you.
  155. 1:Thanks! 2:There is none, AFAIK. 3:Yup, exacttly. by CRConrad · · Score: 1

    Feh! Subject says it all, already -- THIS software sucks extra-bad!

    --

    Christian R. Conrad
    mail me at iki.fi ; same user ID as here