July 2005 - Posts

Monad - MSH Day 2
Thursday, July 14, 2005 9:19 AM

Some cool things about MSH

Accessing different providers as a file system, like the registry:
MSH> cd HKLM:\Software
MSH> dir
Hive: Registry::HKEY_LOCAL_MACHINE\Software

SKC  VC Name                           Property
---  -- ----                           --------
 0   2 AdMuncher                      {AppPath, MigrateDone}
 2   0 Adobe
10   0 Ahead
 5   0 ATI Technologies
 1   0 ATI Technologies Inc`.
 1   0 Battle`.net
 1   0 Blizzard Entertainment
................
MSH>

Another super thing for testing purposes is the (what if) switch: 
MSH> get-process w* | stop-process –whatif
What if: Operation "stop-process" on Target "wdfmgr (772)"
What if: Operation "stop-process" on Target "winlogon (984)"
What if: Operation "stop-process" on Target "WINWORD (3504)"
What if: Operation "stop-process" on Target "WLTRAY (2808)"
What if: Operation "stop-process" on Target "WLTRYSVC (1888)"
MSH>

The (what if) switch will not perform the action, it will only show you what will happen!
In this case it would kill 4 processes

Accessing WMI objects is quite simple and logical:
MSH> $Bios = get-WMIObject Win32_Bios
MSH> $Bios.Name
Phoenix ROM BIOS PLUS Version 3.50 B03
MSH>

You can as many new drives as you want:
MSH> New-Drive Movies FileSystem \\FileSrv\Media\Movies
MSH> cd Movies:
MSH> dir

You can interact with system processes as well:
MSH> $a = Get-Process | where {$_.ProcessName -eq "notepad"}
MSH> $a.Kill()

Well that is it for now I will post some more info later.

 

I finally got my hands on MSH
Wednesday, July 13, 2005 10:22 AM

I am going to keep this short and sweet, MSH kicks ass.

 

Most shells (such as Windows CMD.EXE and the UNIX shells SH, KSH, CSH, and BASH) operate by executing a command or utility in a new process, and presenting the results (or errors) to the user as text.  Text-based processing is the way in which system interaction is done with these shells.  Over the years, a large number of text processing utilities—such as sed, awk, and PERL—have evolved to support this interaction.  The heritage of this operational process is very rich.

These shells also have another type of command; these commands are built-in to the shell and do not start a new process, but run within the process context of the shell.  Examples of built-in commands are the KSH typeset command and the CMD.EXE DIR command. In most shells the number of built-in commands is somewhat small, so over time a large number of utilities that have been created.

The MSH.EXE shell is very different from these traditional shells.   First, this shell does not use text as the basis for interaction with the system, but uses an object model based on the .NET platform.   As we will see, this provides a much different way to interact with the system.  Second, the list of built-in commands is much longer; this is done to ensure that the interaction with the object model is accomplished with the highest regard to integrity with respect to interacting with the system.  Third, the shell provides consistency with regard to interacting with built-in commands through the use of a single parser, rather than relying on each command to create its own parser for parameters.

Later in this document we will discuss how to interact with traditional executables and how they can more fully participate in an object model environment.

 

Some cool things that one can do with MSH.

 

MSH> $a = Get-Process | where {$_.ProcessName –eq “notepad”}

MSH> $a.Kill()

 

This will kill notepad if it is running.

 

You can browse through the registry like a file system and lots more.

 

I have only been playing with it for the last 30 minutes, when I have some more cool things to show, I will post.