Gallery

Shell power for Windows

Posted on 29 Jun 2006 at 11:22

Thomas Lee looks at microsoft's cool new administration shell and scripting tool, powershell, and finds out how it fits into the .NET framework

This script also illustrates another aspect of the way admins work. You could manually inspect each folder in the C drive, but that's slow and with 1,500 folders to manage it simply isn't a useful solution. You could also write a script to check, individually, for the required files, but this is brittle since you'd have to update it every time a new folder is created or an existing folder deleted or renamed. The answer is to spend a bit more time writing a general script, as illustrated above.

Getting at .NET

As you use PowerShell, either from the Command Prompt or via scripts, you can access the power of .NET in three ways: cmdlets, raw .NET access, or Enhanced .NET access. The PowerShell commands are known as cmdlets, and they reach into the .NET Framework to provide you with access to the underlying information but at a more abstract level. Raw .NET access lets you call .NET classes directly from PowerShell, while Enhanced .NET Access provides a number of features that simplify the access to raw .NET Objects and provide a rich set of features to draw on when writing scripts or using the interactive shell.

You could use raw .NET to obtain access to some raw object, process that object using Enhanced .NET access, and then produce and format the output by using cmdlets. The script I showed you above does some of these things to a limited degree - for example, the PSISCONTAINER property that gets checked by the first line of script is an example of Enhanced .NET access. PowerShell extends the base object with added attributes, in this case a Boolean property that indicates whether the object is a container (that is, a folder) or a root element (that is, a file). Then the script employs simple cmdlets like LS and WRITE-HOST to check for the existence of the checksum flag file and to produce output.

PowerShell's cmdlets are small, atomic commands that you can either type at the Command Prompt or place in a script to carry out some operation. Cmdlet names employ a verb-noun naming convention, as in GET-CHILDITEM, which means the base cmdlets tend to have long names. PowerShell therefore provides aliases as a way to write more terse commands: in the above script, I used the alias LS to stand for GET-CHILDITEM.

Cmdlets expose .NET functionality in an admin-friendly and easy-to-use fashion. For example, the GET-PROCESS cmdlet is built on top of the .NET SYSTEM.DIAGNOSTIC.PROCESS class and its GETPROCESSES method for more information on this .NET class). The GET-PROCESS cmdlet returns zero, one or more process objects, as determined by a rich set of input parameters, which you can then operate on by using the STOP-PROCESS cmdlet to stop them running.

While the raw .NET object programmers use is powerful, the PowerShell cmdlets provide and support an admin's view of the system, for example by the consistent naming of cmdlets and parameters, to preserve as much of your existing knowledge as possible. There's rich wildcard support for object naming, which makes it possible to write commands that are both granular and terse. It also supports checking for those actions that may have dangerous side-effects, so you can use the -WHATIF and -CONFIRM parameters on cmdlets like STOP-PROCESS.

You typically use cmdlets whose names begin with GET- to fetch the objects you want to work on, so GET-PROCESS gets active processes, GET-HELP gets help, GET-SERVICE gets services and so on. Once you've got the object you want to manipulate, you can read or update its properties and use other cmdlets to perform operations on it - having got a set of processes using GET-PROCESS, you could stop one or more of them using STOP-PROCESS. PowerShell provides a large set of cmdlets for generating output, which include EXPORT-CLIXML, FORMAT-TABLE, FORMAT-LIST, WRITE-LOG, WRITE-HOST.