Once upon a time, when DOS walked the earth, the command line was the primary user interface for most of our computers. Then, Windows came along, and Microsoft seemed set on leaving the command prompt to dry up and wither into obscurity. Fortunately, Microsoft has again turned its attention to the command line and, in so doing, has produced one of the most compelling new Windows features eWEEK Labs has ever had the pleasure to test: Windows PowerShell.
PowerShell 1.0, which was formerly known by the code name Monad, extends to administrators, developers and enthusiasts a powerful new interface for their Windows machines that’s based on stringing together small, well-defined applications into pipelines—a handy capability on which Linux and Unix administrators have long relied.
However, unlike Linux and Unix shells such as bash or korn, in which strung-together applications pass data to each other as raw text, PowerShell boasts an object-based approach that enables elements to communicate more intelligently with each other.
For instance, in both the bash shell (the default for most Linux distributions) and in PowerShell, you can sort items in a folder by size by piping the output of a “list items” command to a “sort” command. With bash, however, the fact that piped commands pass their output as raw text means that you have to pay attention to text formatting on both ends of the pipeline. If you run the command “ls” without the “-l” argument, the command won’t spit out file sizes, so “sort” won’t be able to sort by file size. On the other end, “sort” needs to be told to sort by the fifth column from the left and to treat that column as numerical data.
With PowerShell, the built-in command (or cmdlet, in PowerShell parlance) that corresponds to “ls” is an object, and “length” is one of its properties. When you pipe the output of this cmdlet, called Get-ChildItem, to the cmdlet Sort-Object, you can tell it how to sort by file length appending the word length. While it happens that file length is one of properties that Get-ChildItem outputs by default, you can just as easily sort by other, hidden-by-default properties, such as LastAccessTime.
One great thing about PowerShell’s object-based approach is that it reduces the need to learn application-specific arguments and quirks in favor of learning habits and syntax that apply to many different commands and operations. We also appreciated that PowerShell ships with a large set of pre-defined aliases for its cmdlets that make the product’s learning curve less steep. For instance, the cmdlet Get-ChildItem is aliased to both “ls” and “dir,” and the cmdlet Sort-Object is aliased to “sort.”
What’s more, PowerShell offers very good tab-completion, which works not only with cmdlets and files in the current directory but also with cmdlet arguments. In addition, PowerShell’s cmdlets and concepts are all well-documented and close at hand via the Get-Help cmdlet. PowerShell’s help pages look very much like Linux/Unix man pages, although we missed the ability to page up and down through the help articles, as we’re accustomed to doing from within Linux.
Probably the best usability/discoverability attribute of PowerShell, however, is the Get-Member cmdlet, which fetches all the properties and methods available for a given object. We used Get-Member quite a bit while poking around PowerShell and figuring out what we could do with it. We expect that PowerShell will become a major productivity boon for Windows administrators as Microsoft expands the objects through which PowerShell users may control Windows.
In the meantime, we could use PowerShell cmdlets to manipulate services and processes and to fetch WMI (Windows Management Instrumentation) data. We also could browse the system registry through an ingenious PowerShell capability that exposes registry hives as if they were disk drives.
We also could use PowerShell to take control of Windows COM (Component Object Model) objects.
As with other shells, PowerShell is intended to serve as an environment for scripting, but, for security reasons, PowerShell is configured by default to be used only interactively, from its command line.
We could adjust the execution policy of our PowerShell installation: RemoteSigned runs unsigned local scripts and requires a digital signature for scripts marked as downloaded from the network, AllSigned requires a digital signature for any script, and Unrestricted runs scripts without digital signing restrictions. As a further safeguard, PowerShell scripts cannot be run by double-clicking on them.
Windows PowerShell, which depends on Version 2.0 the .Net Framework, is freely available for download at microsoft.com/powershell in versions for Windows XP SP2 and Windows Server 2003 (for the x86, x64 and Itanium platforms). At press time, PowerShell wasn’t yet available for the RTM (released to manufacturing) version of Vista—a puzzling gap, considering that Vista early adopters are likely to be eager to run PowerShell on their new Vista systems.
We managed to install PowerShell on an RTM Vista box following directions we found here. We recommend, however, sticking to Windows XP or Windows Server 2003 for PowerShell testing until the Vista installer ships.
Advanced Technologies Analyst Jason Brooks can be reached at jason_brooks@ziffdavis.com.
Check out eWEEK.com’s for Microsoft and Windows news, views and analysis.