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.