For years Windows users and administrators have had to live without an inadequate scripting shell environment. Sure, there is Perl, Python, and CMD.exe, but those never really could keep up with the all-in-one Swiss army knife of a shell Unix administrators gets to use.
Enter stage left: Windows PowerShell.
Described as both a shell and a scripting language and designed for IT professionals and administrators, PowerShell provides all of the functionality expected from a scripting shell plus some more. There is a free book available online that serves as a nice introduction to the program. The download requires you to log into your .NET passport account. If that’s a problem for anyone, let me know.
It is important to note how PowerShell is fundamentally different from all other shells. Unlike most shells, PowerShell uses an object-oriented model based on the .NET framework for input and output. Here is an excerpt from Frank Koch’s free text, “Windows Powershell” explaining what that means:
PowerShell’s object-oriented concept makes the standard parsers for Unix shells (analyze/evaluate) and text-based information with all its problems and error proneness completely superfluous. To make this clearer we provide the following example: Assume that you would like to have a list of all processes that consume more than 100 handles. With a traditional Linux shell you would call up the command for displaying processes (ps -A). The command then returns a text list. Each line would contain information about a process, separated by spaces. You would parse these lines with a tool, filter out the process ID and then query this with another program to find the handle number. You would then parse these text-based results, filter out the relevant lines and then finally display the relevant text.
Depending on how well cutting and filtering of information from the text lists functions, this approach is more or less reliable. But, for example, if the title of a column in the output changes and the process names are then too long, you will certainly have problems.
PowerShell uses a fundamentally different approach. You also start with the command get-process, which returns all running processes in the operating system. Only here they are returned as an object list made of process objects. These objects can then be investigated for their attributes and directly queried – therefore you do not have to examine any text lines and split them into columns.
There is another good explanation that can be found by following this link.
I haven’t spent a lot of time exploring the uses or getting comfortable with the syntax, but it quickly becomes apparent how powerful and useful this application is. Consider the following script:
(from “Windows Powershell” by Frank Koch”)
$a = new-object -comobject excel.application
$a.Visible = $True
$b = $a.Workbooks.Add()
$c = $b.Worksheets.Item(1)
$c.Cells.Item(1,1) = “Service Name”
$c.Cells.Item(1,2) = “Service Status”
$i = 2 get-service | foreach-object{ $c.cells.item($i,1) = $_.name;
$c.cells.item($i,2) = $_.status; $i=$i+1}
$b.SaveAs(“C:\Users\Public\Documents\Test.xls”)
$a.Quit()
Can you guess what that does? Here’s the neatest part, because of line 2 ($a.Visible=$True) I was able to watch all of this happening in an instance of Excel that was opened in the background. The scope and capability of this application leads to my next point, security.
It appears that Microsoft has learned some lessons from JavaScript and ActiveX scripting in regards to security. Scripting is disabled by default, meaning any local or remote scripting file (*.ps1) cannot be run. Built into PowerShell are four different security settings, in regards to signed scripting.
Restricted (Default) - No scripts are run
Allsigned - Only signed scripts are run
Remote - All remote scripts must be signed. Unsigned local scripts will run
Unrestricted - All scripts are run
Beware, this setting can be changed by any user that can run the application, even if they aren’t an Administrator. It’s very nice to see Microsoft implementing some security by default considering this will be included into Windows Server 2008 (Longhorn).
Windows Powershell
Powershell Team Blog
Windows PowerShell Script Repository
