“Welcome to the Script Center portal for the Microsoft Shell (also known as MSH or Monad), Microsoft’s next-generation command-line and scripting environment. We’ll be adding new content and scripts periodically – so check back with us every once in a while. We’d like to be sure we’re continuing to meet your needs, so let us know what you’d like to see here.”
I have been playing with it, its pretty nice lots of cool stuff.
u can pipe text/streams like unix
cmd | cmd | file.txt
you can also pip objects
users | user | cmd | report.txt
all your system variable become mountable and the registry is mountable, the shell takes alot from Perl
so all kinds of things are possible they also tried to have strong nameing and have things make sense like in vms
so its a good thing, u can even call into .NET and script that. very cool.
-Nex6
Actually, this is my worry.
you can also pip objects
users | user | cmd | report.txt
I’m not going to condemn piping objects, it’s all good.
But I do have one concern.
When working from the command line, Unix shells works so well because they essentially communicate using streams of bytes with implied structure, i.e. lines with tokens seperated by white space.
That structure is very loose, but quite universal. The ubiquitous nature of the text format allows a lot to be done with the limited tool set. They all under stand text, basically, and mung up the stream is all sorts of different ways.
But when you start piping through objects, it seems to me (having no experience with Monad/MSH) that your command set is going to balloon, simply because you’re going to have a commands that only work on specific objects.
Let’s take a contrived example from Unix:
Top 10 large files in a directory.
ls -l | sort -r -n +4 -5 | head | awk ‘{print $9}’
(Why cut(1) can’t use whitespace as a delimiter is beyond me, but, anyway).
Now, clearly, the last 3 parts of the pipe are a roundabout way of doing things. But the point is that they’re all rather stupid and simple programs, and quite ignorant of each other.
But when you start dealing with objects, the binding between programs starts getting much tighter.
In the example above, you have the ‘users’, ‘user’, and ‘cmd’ commands. ‘users’ probably gives a list of users, ‘user’ perhaps selects a user give a list, and ‘cmd’ takes a user argument and performs some action.
Now, I dunno about you, but many times in the past I’ve taken pipes like these, and dumped intermittent results into files, beat on the files with vi, and then fed the results in to the rest of the pipe.
Is that going to be possible in cases like above? with the ‘users’ command?
I don’t know.
I mean, I welcome the advances portrayed by Mondad. And I think it’s nice that they’re going to have a .NET aware scripting language.
But I’m curious how truly nimble the command shell will be with the potential for a much larger library of object specific commands.
channel9 video with the master of monad in his own words.
http://channel9.msdn.com/Showpost.aspx?postid=127819
there are 3 vids i think altogether.
the monad team took alot form Perl,bash and c# with Perl being the biggest part of that.
and in the future all the admin tools are going to be built ontop of monad so like in unix, you will be able to script anything with the same functionallty as the gui tool.
its a very good step forward.
-nex6
“Let’s take a contrived example from Unix:
Top 10 large files in a directory.
ls -l | sort -r -n +4 -5 | head | awk ‘{print $9}’ ”
And then came GNU ls :
ls -S|head -10
But when you start piping through objects, it seems to me (having no experience with Monad/MSH) that your command set is going to balloon, simply because you’re going to have a commands that only work on specific objects.
This isn’t really an issue with MSH due to its standardized integration points and common object model. Because of this, you can use a standard set of filters or commands on different types of objects.
Get-ChildItem, for example, can be used to return a collection of files/directories, or (for something like the above user example) the users in an ActiveDirectory store. And should the need arrise, you can still pipe just the text output from the objects.
Let’s take a contrived example from Unix:
Top 10 large files in a directory.
ls -l | sort -r -n +4 -5 | head | awk ‘{print $9}’
(Why cut(1) can’t use whitespace as a delimiter is beyond me, but, anyway).
Now, clearly, the last 3 parts of the pipe are a roundabout way of doing things. But the point is that they’re all rather stupid and simple programs, and quite ignorant of each other.
…
Now, I dunno about you, but many times in the past I’ve taken pipes like these, and dumped intermittent results into files, beat on the files with vi, and then fed the results in to the rest of the pipe.
Is that going to be possible in cases like above? with the ‘users’ command?
MSH version of the above script:
gci | where { $_ -is [io.fileinfo] } | sort Length | select -f 10
If you take out the “where { $_ -is [io.fileinfo] }” part, you’ll get the top 10 files and directories instead of just files. “where”, “select”, and “sort” are standard filters you can use on different properties of objects.
Output looks like this:
Directory: FileSystem::C:
Mode LastWriteTime Length Name
—- ————- —— —-
-a— 1/30/2005 5:34 PM 10 file1.ext
-a— 1/30/2005 5:34 PM 55 file2.ext
-a— 3/17/2005 11:33 PM 465 file3.ext
-a— 12/20/2005 11:42 PM 8192 file4.ext
.
.
.
-a— 3/12/2005 6:04 PM 2068092 file10.ext
sort Length -Descending or
sort Length -des (you only need to type enough to disambiguate the parameter)
will reverse the above sort order
You can redirect the output to a file:
gci | where { $_ -is [io.fileinfo] } | sort Length | select -f 10 >file.txt
and pull it back in later (though it’s just text now and you’ll have to eiter work with it as text or feed it into an object (like reading each line into an array). If you want to persist it as an object, you could export it as CliXML (Export-CliXML), then import it back into MSH (Import-CliXML). Then you can manipulate it as an object again instead of text.
> (Why cut(1) can’t use whitespace as a delimiter is beyond me, but, anyway).
Sure you can delimit the space with -character for example: ‘echo foo bar foobar | cur -d -f2’ returns “bar”. Remeber to have two spaces after the , one for the parameter itself and one for separating the parameters.
It is the only unique Vista feature. Every thing else is a copy of some other OS. Even though *nix have had “good” shells for years MS is the first full fledged new shell to come out in years. It is a feature I wish Apple would copy for OS X. Take Apple scripting to a whole new level.
I’m not sure but i’d be concered with the exploitability of all of this. Remember those scripts that if you typed into word would automatically run?
This whole scripting power of windows might be a big slap in the face to anyone who insists on running as administrator. Logging in as restricted accounts in windows is going to be a must.
This is a powerful tool to be exploited by the good and the evil.
Edited 2005-12-21 19:40
True:
but MS is biggest part on the virus’s is compatibilty
of legacy stuff. .NET has much better security frameworks then anything MS had before it.
and all the user and compatibilty is what the Virus’s use for the most part.
-Nex6
This whole scripting power of windows might be a big slap in the face to anyone who insists on running as administrator. Logging in as restricted accounts in windows is going to be a must.
MSH scripts have no shell association by default, and remote scripts/scripts originating from the internet have to be signed before they will run. You can also require all scripts to be signed if you want.
MSH scripts have no shell association by default, and remote scripts/scripts originating from the internet have to be signed before they will run. You can also require all scripts to be signed if you want.
So in order to make this be a problem one would need to have access to an account that can assign a default association to MSH scripts and make them available locally, optionally signed? I suspect that even an MSCE could do that, much less a skilled hacker/cracker. (o;}
So in order to make this be a problem one would need to have access to an account that can assign a default association to MSH scripts and make them available locally, optionally signed? I suspect that even an MSCE could do that, much less a skilled hacker/cracker. (o;}
If they could, you have other issues to worry about besides someone running MSH scripts. On a properly secured box, they’d have to depend on similar methods to hacking any box (none of which involve .NET or MSH) to gain access, or have physical access.
How is this new and unique to Vista? Programmable shells are anything but new and at this point, it’s a long stretch to call them innovative.
shells have been arround for every OS for awhile some are good and some are bad. but: this is the first one that can pipe and pass arround objects and lets you script into .NET basicly scripting C#.
-Nex6
this is the first one that can pipe and pass arround objects and lets you script into .NET basicly scripting C#.
Plumbing in Plan9 can’t write into .NET or use C# commands but it handles objects doesn’t it? Unless I’m wrong, which is likely in this case, object oriented shells have been around for a while and exposing .NET through C# would be a security hole that now appears to be fully integrated into Vista if Monad ships with it or installs by default.
As I recall the day after the Monad beta was announced some exploit code was published that used this “feature”. Any idea if that has been fixed yet?
object oriented shells have been around for a while and exposing .NET through C# would be a security hole that now appears to be fully integrated into Vista if Monad ships with it or installs by default.
There are no holes to be opened using .NET. You’d have to have the right permissions to be able to run the script. There’s no default association for scripts. And scripts originating from untrusted sources such as the internet have to be signed first (by default) before they can run.
As I recall the day after the Monad beta was announced some exploit code was published that used this “feature”. Any idea if that has been fixed yet?
The code wasn’t exploit code. It was a script written in MSH. The same could’ve been written in Unix shells, WSH, batch, or other scripts. It wouldn’t even run with the defaults for MSH for the reasons stated above. As posted yesterday, here’s a link explaining why it wouldn’t run.
http://www.leeholmes.com/blog/MonadAndTheFirstVistaVirus.aspx
So what of all those WSH scripts, would you convert them or get off the merry go round and go with MKS tool kit or some other shell that will be ported to future versions of windows?
So what of all those WSH scripts, would you convert them or get off the merry go round and go with MKS tool kit or some other shell that will be ported to future versions of windows?
you can use them from within MSH (also COM objects)
You sure about that? I search msdn and see only accessing the ecma script objects via winFX sdk but nothing on interpeting it.
You sure about that? I search msdn and see only accessing the ecma script objects via winFX sdk but nothing on interpeting it.
Basically you can just run the script from within MSH using cscript.exe, then you can manipulate the output in MSH by piping it through cmdlets. I don’t see any examples that deal with that specifically. Most of the WSH/MSH-related examples deal with doing equivalent operations w/ WMI or COM using MSH rather than WSH.
OMG guys i just sharted in my pants!!! Smells really ugly!
Unix/Linux differs from Windows in that every Unix admin knows how to write a shell script and uses shell scripts to do stuff once in a while. 99% of Windows would not know what a shell script does even if it punched them in the face, so who is going to use this shell scripting facility? Will Microsoft certification begin to include some real computer education for the mostly half-wits that call themselves Windows admins?
My advice to Microsoft: Keep things the way they are. Keep bad-mouthing Unix as “old and antiquated” but stop re-inventing a wheel that has workded well for over 30 years. That way you will maintain some veneer of credibility.