Monad released!

[dman]

Manually typing in a command to "find all files in C:\temp containing the string 'test' with the extention .tmp" is all well and fine. But anything more complex than that I'm going to write a full blown script.

From monad.rtf documant:

Scripts

Commands may be aggregated into files, or "scripts," and MSH language scripts may be run from within an MSH.EXE session.  To be recognized as an MSH script the script must have the extension .msh.  To run an MSH script, simply type the name of the script without the extension.  The prerelease will look in the $ENV:PATH for files with the .msh extension and will execute the first script found by the typed name.  Arguments to the script can just be added to the end of the script name.

MSH> mshscript arg1 arg2

Scripts that are run in this way run in a new scope.  This means that variables that have been created on the command line are safe from modification unless the script explicitly wants to change the value in a different scope.  If you want to run the script in the current scope then execute the script as follows:

MSH> . mshscript arg1 arg2

The "." tells the shell to execute the script in the current scope.  To run it from a cmd.exe prompt use this format:

C:\> msh –NoLogo –Command mshscript arg1 arg2

I think you may be missing the point that monad is also scriptable.

Edited June 21, 2005 by dman

[Noise]

@ dman,

So this means we will basically have three different ways to create scripts for Windows machines. The good old fashoned CMD shell, VBS/JS/WSH and now Monad. (I won't mention the k/c shells available with Microsoft Service for UNIX - shhh )

All are capable of scripting. Monad and Cmd also have the ability of direct input. Monad and VBS seem equil in power and capabilities; ie. creating functions, nested loops, all that programming mumbo jumbo.

I guess it boils down to which one is easier for the Administrator to use. Assuming notepad.exe is your editor, which one is the easiest to code for. Judging from Martins examples it seems like Monad is more intuitive. I really cant judgement call on this without experience with Monad.

@ Martin,

A couple questions if you please, sir.

What do you see as Monad's limitations?

You have extensive experience with cmd and vbs, how does Monad compare?

Does Monad allow control of other PC's on the network? If so, do these PC's need Monad installed or is control through DCOM/WSH?

[Martin Zugec]

Ok, I will first answer last question Monad dont have support for remote computing - it will of course be available in final version, now it is not.

Monad (current version) have only two limitation - dont support remote networking and second thing is aliases cant contain parameters.

Now for the harder part - comparing CMD vs. WSH vs. Monad.

Well, it wont be so hard at all Monad containt all features of CMD + WSH + much more.

WSH

Monad have same advantages as WSH.

For example accessing WMI objects is quite simple and logical:

MSH> $objBios = get-WMIObject Win32_Bios
MSH> $objBios.Name
Phoenix ROM BIOS PLUS Version 1.10 A02
MSH>

You can using objects in Monad using cmdlet net-object, so you can do the same as in vbscript.

$objShell = New-Object –ActiveX “WScript.Shell”

CMD

You can use everything from cmd in Monad, so there is no reason why not using MSH instead of cmd. Implementation of StdIn/StdOut is quite simple to do, so I didnt encounter any compatibility problems at all.

What is the main reason to use MSH for me is that

a.) in 3-5 years (according to MS) every program from MS will have support for Monad. So you could do (similar to *nix) everything from cmd.

b.) it is frontend to .NET. I cannot fully work with it yet (as I am not programmer), but it is quite similar process like WMIC - but it is much more powerfull. It is just not another shell, it is shell + language + framework.