Advice for Windows XP Scripting, WSH versus PowerShell

Question

After much experience scripting in the Unix/Linux open-source world, using languages such as Bourne Shell, Perl, Python, and Ruby, I now find myself needing to do some Windows XP administration scripting. It appears that the legacy environment is Windows Script Host (WSH), which can use various scripting languages, but the primary language is VBScript, and is based on COM objects. However, the future appears to be Windows PowerShell, which is based on .NET.

I haven't done Basic since Applesoft in the 1970s, so I'm not keen on learning VBScript, although I did learn enough to write a small script to mount network drives. If I'm going to spend time to really learn this, I'm leaning towards investing my time in the .NET PowerShell environment, if it truly is the future. I did some C# Windows Forms programming a couple of years ago, so I have some exposure to .NET, which also makes PowerShell attractive.

Understanding that no one has a crystal ball to predict the future of Microsoft, I would like hear from anyone who is a PowerShell user and thinks it's worthwhile, or if there is anyone that knows of serious drawbacks to PowerShell, and recommends that I stay away from it.

Update: I ended up using WSH/VBScript for a particular script that I am installing as a startup script on user's Windows XP workstations. All I have to do is copy it to their Startup folder, and I'm done. However, I only learned enough WSH to accomplish this one job. I am glad to see that PowerShell is the future, and when I have more complicated scripting tasks, I'll turn to PowerShell.

Answer 1

Is it "worthwhile"?

Absolutely. Here are number of reasons why.

1. More and more Microsoft products are based-on PowerShell - e.g. Exchange Server 2007, SQL Server 2008, etc.
   
2. PowerShell can access Microsoft .NET.
3. Easy to learn - You only need few commands to explore capabilities of PowerShell - e.g.) Get-Command, Get-Help, Get-Member, etc.
4. Most of commands are aliased and mapped in a way that they are similar to DOS or *NIX shell commands - e.g.) "ls" and "dir" are aliases for "Get-ChildItem", "cd" for "Set-Location"
5. It's a great developer's tool - Since PowerShell can access .NET library, you can prototype some of your .NET functionalities in PowerShell
6. You can navigate around Registry, Certificate, Environment Variables, etc as if they are file system - You use the same command you use in FileSystem to navigate around - e.g.) cd HKLM:\

Drawbacks:

1. PowerShell version 1.0 does not support Remoting (supported in 2.0) and creating a new thread(using System.Threading.Thread, but will support background jobs in 2.0)
   
2. Learning curve can be long if you are not used to C#/Java based language
   
3. It's hard to create generic .NET objects
   • e.g.) creating a generic List<int> collection is like following

$l = new-Object System.Collections.Generic.List``1[[System.Int32]]