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 thats 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 wont spit out file sizes, so “sort” wont 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 the 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 PowerShells 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 Power-Shell ships with a large set of predefined aliases for its cmdlets that make the products learning curve less steep.
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 Power-Shell users may control Windows.
In the meantime, we could use PowerShell cmdlets to manipulate services and proc-esses 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, and we could use PowerShell to take control of Windows COM (Component Object Model) objects.
As with other shells, Power–Shell is intended to serve as an environment for scripting, but, for security reasons, it is configured by default to be used only interactively, from its command line.
PowerShell can be in–stalled using three execution policies: 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.
PowerShell, which de–pends on .Net Framework 2.0, 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 wasnt yet available for the RTM (released to manufacturing) version of Vista.
We managed to install PowerShell on an RTM Vista box following directions we found at gaurhothw.spaces.live.com/blog/s!52B0837064D0B275!106.entry. 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 .