There have been many command-line shells in the history of computer OSs. UNIX traditionally has
always been a shell-oriented OS. Linux follows the same by providing a powerful set of command-line shells for
you to perform various powerful tasks from there itself. However, Microsoft OSs have generally had only simpler shells-
COMMAND.COM or CMD.EXE. These are not popular or powerful choices for power users.
Microsoft is now preparing a completely new command-line shell that will be available in 'Longhorn' and installable in Win XP and Win 2003. This shell is currently in beta and is codenamed 'Monad', the Microsoft Shell or MSH in short. MSH has a number of features that many other shells don't. Traditional shells work in a way that minor commands are part of the shell itself and major commands are executable programs that are run from the path, eg, in Windows, DIR is an internal command, whereas ATTRIB is an external EXE. This is the same way that other shells (such as on Linux) work too.
|
However, MSH works in a different way. Instead of using internal and external commands, MSH uses an object-oriented
approach. So instead of working with 'commands' you work with object, methods and properties. Commands in the MSH are nothing but methods of objects in the MSH namespace and are known as CmdLets (pronounced as Command-Lets). The information
returned by MSH corresponds to .NET objects. This is also the reason that MSH requires the .NET Framework 2.0 to be installed for the power that it provides. External commands that are present (in the PATH naturally) are still called in the 'standard' way. However, all commands that are part of the MSH now work in the method
described above.
Let's take a simple example to understand all this. Let's say you wish to terminate a particular running program from the command line. For doing this, you must first find out the process ID of the application. The CmdLet that gets you this information is get-process.The result of running this in MSH is as follows.
MSH> get-process
. . .
The information you see on each line is of the object .NET type System.Diagnostics.Process. What we wish to do is filter out only the process for that application-say Notepad. To do this,
you must change the result of the get-process call with a parameter '-Processname' like this:
|
MSH> get-process -Processname notepad
Microsoft gives aliases for these common commands. So instead of typing the entire command as shown above, you can also get the same result by typing 'ps notepad'. Now we come to
getting the ID property of the process. This is as simple as appending a period and 'property-name' after the command.
For instance, to display the ID of the notepad application this is what you do:
MSH> echo "The Process ID of NotePad is: ",(ps notepad).ID
The Process ID of NotePad is:
2392
When you enter (ps notepad).ID it gets the process object for the notepad application and retrieves the ID property of that object. Since you can get the ID now directly from the process command, to terminate it, issue:
MSH> stop-process (ps notepad).ID
Or
MSH> kill (ps notepad).ID
Remember everything returns an object-even seemingly standard commands such as DIR. In fact, DIR is actually an alias for get-childitem and returns FileInfo objects, which can be further used like the following :
|
MSH> foreach ($file in dir *.log)
>> {
>> $temp = $file.Name + " " + $file.Length
>> echo $temp | format-list
>> }
>>
0.log 0
actsetup.log 4645
cmsetacl.log 200
COM+.log 10120
comsetup.log 106289
dahotfix.log 3721
dasetup.log 17480
DirectX.log 1057
domainRename.log 995
DtcInstall.log 360
FaxSetup.log 276210
iis6.log 748824
Here, we create a sample for loop that iterates through each LOG file in the current folder. The returned object is stored in the variable $file. A new temp variable is used to store a string that consists of the properties Name and Length of the current object and is then displayed with formatting. The output is shown directly below the command. MSH has a number of powerful
features to let you work within a much more programmable environment. In fact, the next version of Windows as well as major server software such as MS Exchange Server is going to have the
Microsoft Shell built-in to provide management capabilities.
Vinod Unny, Enterprise InfoTech