Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Windows Operating Systems Software IT

Next-gen Windows Command Line Shell Now in Beta 668

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."
This discussion has been archived. No new comments can be posted.

Next-gen Windows Command Line Shell Now in Beta

Comments Filter:
  • Re: No Thanks (Score:5, Informative)

    by torpor ( 458 ) <ibisum.gmail@com> on Sunday June 19, 2005 @12:12PM (#12856452) Homepage Journal
    Ok, but does bash or ksh run on windows? This is for their own OS, not unix.


    Of course it does, silly [cygwin.com].
  • Re: No Thanks (Score:0, Informative)

    by PyWiz ( 865118 ) on Sunday June 19, 2005 @12:14PM (#12856465)
    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 [cygwin.com]? 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.
  • by TheAncientHacker ( 222131 ) <TheAncientHackerNO@SPAMhotmail.com> on Sunday June 19, 2005 @12:29PM (#12856560)
    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>_

  • by Utopia ( 149375 ) on Sunday June 19, 2005 @12:33PM (#12856581)
    Windows has had symbolic links since Windows 2000. It was called junction points.

    In XP it was renamed as reparse points.




  • Re:backslashes (Score:3, Informative)

    by Tony Hoyle ( 11698 ) <tmh@nodomain.org> on Sunday June 19, 2005 @12:45PM (#12856647) Homepage
    That's just a cmd.exe (and explorer.exe) limitation.

    The NT kernel fixed the backslash brokenness years ago.
  • Groovy (Score:2, Informative)

    by Anonymous Coward on Sunday June 19, 2005 @12:54PM (#12856688)
    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.
  • Re:monad (Score:1, Informative)

    by Compholio ( 770966 ) on Sunday June 19, 2005 @01:02PM (#12856723)
    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.
  • by mpeg4codec ( 581587 ) on Sunday June 19, 2005 @01:07PM (#12856753) Homepage
    The previous text is the interface to XP's default shell, cmd.exe.
  • by Anonymous Coward on Sunday June 19, 2005 @01:19PM (#12856805)
    How Can I get MSH?

    To get MSH, first navigate to http://beta.microsoft.com/ [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.
  • by Anonymous Coward on Sunday June 19, 2005 @01:24PM (#12856830)
    What the fuck where you trying to say?.

    Not to be pedantic about your pedantry, but I think you meant were, not where.
  • by Ingolfke ( 515826 ) on Sunday June 19, 2005 @01:38PM (#12856892) Journal
    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 [microsoft.com] 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.
  • Re:backslashes (Score:1, Informative)

    by Anonymous Coward on Sunday June 19, 2005 @01:50PM (#12856942)
    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.
  • Re:backslashes (Score:4, Informative)

    by m50d ( 797211 ) on Sunday June 19, 2005 @01:51PM (#12856947) Homepage Journal
    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.
  • Re:First impressions (Score:4, Informative)

    by Ravatar ( 891374 ) on Sunday June 19, 2005 @01:58PM (#12856986)
    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
  • Re: No Thanks (Score:1, Informative)

    by Osty ( 16825 ) on Sunday June 19, 2005 @02:48PM (#12857222)

    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" [msdn.com]. 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).

  • Re:whoosh! (Score:3, Informative)

    by julesh ( 229690 ) on Sunday June 19, 2005 @03:09PM (#12857313)
    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.
  • by moonbender ( 547943 ) <moonbenderNO@SPAMgmail.com> on Sunday June 19, 2005 @03:09PM (#12857315)
    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. ;)
  • Yes you can (Score:2, Informative)

    by DigitlDud ( 443365 ) on Sunday June 19, 2005 @03:27PM (#12857399)
    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.
  • Re: No Thanks (Score:3, Informative)

    by julesh ( 229690 ) on Sunday June 19, 2005 @04:17PM (#12857650)
    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".
  • Re: No Thanks (Score:3, Informative)

    by ucblockhead ( 63650 ) on Sunday June 19, 2005 @05:25PM (#12858072) Homepage Journal
    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.
  • by grouse ( 89280 ) on Sunday June 19, 2005 @05:46PM (#12858201)
    The link says the story might be apocryphal, but David Korn confirmed it right here on /. [slashdot.org]
  • Re:whoosh! (Score:2, Informative)

    by brpr ( 826904 ) on Sunday June 19, 2005 @05:59PM (#12858309)

    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.

  • Re:First impressions (Score:3, Informative)

    by nachoboy ( 107025 ) on Sunday June 19, 2005 @09:13PM (#12859383)
    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 [microsoft.com], I was already sold on fsum [slavasoft.com].
    HTTP Downloads: I use wget for Windows [space.tin.it].
    Patch Scanning: I use MBSA [microsoft.com] 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 [microsoft.com] to compress.
    zip Compression Tools: Free add-on [winzip.com] 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

  • Re: No Thanks (Score:2, Informative)

    by leonard_chung ( 658100 ) on Sunday June 19, 2005 @10:01PM (#12859610) Homepage
    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

So you think that money is the root of all evil. Have you ever asked what is the root of money? -- Ayn Rand

Working...