Windows IT Pro is the leading independent community for IT professionals deploying Microsoft Windows server and client applications and technologies.
  
  
  Advanced Search 


September 28, 2006

Using Windows PowerShell

RSS
Subscribe to Windows IT Pro | See More Scripting Articles Here | Reprints | Or get the Monthly Online Pass—only $5.95 a month!

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.

End of Article



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 ...

MysterMask September 30, 2006 (Article Rating: )


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.

buile September 30, 2006 (Article Rating: )


You must be a registered user or online subscriber to comment on this article. Please log on before posting a comment. Are you a new visitor? Register now




Top Viewed ArticlesView all articles
Anti-Virus Vendors Prepare for War with Microsoft ... Again

When Microsoft announced its Windows Live OneCare security and PC health product over five years (as MSN OneCare), Symantec, McAfee, and the other consumer-oriented security vendors reacted with stunning vigor. ...

What You Need to Know About Microsoft's x64 Server Product Plans

What do Longhorn Server, Windows Compute Cluster Server, and Windows Vista have in common? The x64 platform. ...

Command Prompt Tricks

One reader shares his tip for setting up the command prompt to reflect a remote path. ...


Windows OSs Whitepapers Why SaaS is the Right Solution for Log Management

Related Events WinConnections and Microsoft® Exchange Connections

PowerShell 201 - eLearning Series with Paul Robichaux

PowerShell 101 - eLearning Series

Check out our list of Free Email Newsletters!

Scripting eBooks Keeping Your Business Safe from Attack: Encryption and Certificate Services

Best Practices for Managing Linux and UNIX Servers

Building an Effective Reporting System

Related Scripting Resources Introducing Left-Brain.com, the online IT bookstore
Looking for books, CDs, toolkits, eBooks? Prime your mind at Left-Brain.com

Discover Windows IT Pro eLearning Series!
Clear & detailed technical information and helpful how-to's, all in our trademark no-nonsense format

Test Drive IT Solutions and Get Free Music Downloads
Solve your toughest IT problems with these free downloads and receive 5 free music downloads!


Windows IT Pro Home Register FAQ for Windows WinInfo News
Europe Edition About Us Contact Us/Customer Service Media Kit Affiliates / Licensing  
SQL Server Magazine Office & SharePoint Pro DevProConnections IT Job Hound ITTV
IT Library Technology Resource Directory Connected Home asp.netPRO Windows SuperSite 
 
 Windows IT Pro is a Division of Penton Media Inc.
 © 2009 Penton Media, Inc. Terms of Use | Privacy Statement | Reprints and Licensing