Last week, we looked at Microsoft's upcoming new command-line environment, Windows PowerShell. This week, I'd like to examine PowerShell a bit more deeply.

First, though, I wanted to address a few issues that seem to be confusing users. For the time being at least, PowerShell won't be replacing the cmd.exe MS-DOS-based command line environment that's always shipped in Windows. Instead, PowerShell will gradually replace cmd.exe in upcoming Windows versions, though it's likely that cmd.exe will continue to be offered for backward compatibility. Currently, it's available via a separate icon in the Start Menu upon installation.

Second, PowerShell won't be replacing the GUI-based management tools that Microsoft and third parties provide, typically hosted in the Microsoft Management Console (MMC). Instead, the company realizes that some management tasks simply lend themselves to automation, and for such tasks a command-line-based environment works best. It's just that cmd.exe wasn't particularly functional. Going forward, Windows administrators will be able to mix and match between GUI and command-line tools. (And, of course, PowerShell will be used with non-Windows products, such as Microsoft Exchange Server, as well.)

PowerShell requires a non-beta version of Microsoft. NET Framework 2.0 and inherits many of that platform's object-oriented goodness. Specifically, individual PowerShell commands (cmdlets), or small commands, pass structured textual information between each other as objects. As mentioned previously, PowerShell is consistent in that each cmdlet that's available in the environment accepts input and provides output in predictable, consistent ways. Take that, UNIX.

In any event, from the PowerShell command line environment, which provides a prompt in the form of "PowerShell [path]>" (as in, "PowerShell C:\Documents and Settings\Paul>"), you can perform a number of useful functions.

The most obvious is cmdlet completion. Type the beginning of a cmdlet (e.g., "get" without the quotes) and then press the Tab key repeatedly to cycle through all the available cmdlet commands. In the example cited above, you'd see such commands as "get-command," "get-content," "get-credential," and many others. This is handy if you can't quite remember a cmdlet, but it's also handy when you just want to save time; you can type the first part of the cmdlet and complete it with the Tab key.

As an example, a cmdlet called "get-process" returns a list of information about the currently running processes. You can trim that list down in a variety of ways. For example, the following line of code would return only those processes that begin with the letter 'c':

get-process c*

Likewise, the following would return only those that begin with the characters "cli":

get-process cli*

In each case, the output is provided in a neatly laid out table of text, which cmdlets are designed to both create and consume. Note too that cmdlets follow a consistent verb-noun form (as in get-process). This naming convention should help you remember cmdlets because the names are so similar to the tasks they're attempting to accomplish.

I'd hoped to accomplish a lot more, but I'm already out of space. PowerShell provides nice looping and conditional features, variable scoping, and much of the functionality you'd expect from a full .NET programming language. I'll examine those features--and how PowerShell can make an admin's life much easier--in a future commentary.

Reader Comments

"PowerShell is consistent in that each cmdlet that's available in the environment accepts input and provides output in predictable, consistent ways. Take that, UNIX." Idiot. Unix does that since more than 20 years. This is the usual comment of a Windows dummy who does not even grok what the philosophy behind a good OS is. It's not featureitis - it's a set of tools and feature closely working together and still be completely interchangeable. I'd say Redmond should start cleaning up their filesystem mess before trying to copy more advanced features like doing a proper command shell ...

The idea of PowerShell using objects as output is fantastic. However, I'm tired of seeing useless rehashes aimed at beginners that do nothing to help beginners. How many times do we have to see get-process? I was incredibly happy when I heard about PowerShell. However, it has proven annoying, and contrary to the claim of consistency-- inconsistent. Two articles in WindowsITPro mag do little to suggest the authors use PowerShell enough to understand the difficulties (espeically due to haphazard documentation) in doing anything beyond what's *already* in the documentation. As an example, "help where-object" does not tell you about the matching statements (-eq -gt, etc) available to this cmdlet. Also, many tutorials reference object properties in sample commands (I see the same examples over and over, and this articles use of get-process is no exception), while never showing how to find those properties. Finding properties is a basic building block skill needed for PowerShell. I assume your future articles will have useful content regarding PowerShell. Thanks, > Type the beginning of a cmdlet (e.g., "get" without the quotes) > and then press the Tab key P.S. that has never worked. Anyways, the idea of starting cmdlets with a verb only makes them inefficient and tedious to type. In my opinion it breaks an object-oriented approach by making it an action oriented approach. So, instead of having a one-stop-shop cmdlet for services with a single help file, there are multiple commands covering each action each with their own help that I have to remember.