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

Powershell is definitely the way to go if you tend to look forward but it has to be installed separately on Windows before 7 which might make WSH a more attractive target if you just want to deploy scripts that run without further dependencies. Also, .NET isn't included yet on ancient Windows versions like XP which further raises the bar.

If you had some exposure to .NET you should find Powershell pretty intuitive, however. And especially in Windows Server environments it seems to quickly become the default for command-line administering since nearly all newly-released server components ship with custom Powershell cmdlets. So Powershell seems to be a path for Microsoft they want to follow for a while. Heck, they didn't even bury COM so far so I'd expect Powershell to live at least a decade longer, since they position it as the automation and scripting environment for administrative tasks.

Also I found an object-based pipeline, while it took me a while to get accustomed to it, very powerful and easy to use in the end. Certainly simplifies many things that require sed/awk on *nixes.

That being said, I still use Windows batch files for many stuff that should run on Windows without any more dependencies but that's just a dirty habit of mine :)

Answer 2

The main advantage of WSH is that it's been installed by default since Windows 98, possibly even Windows 95, but as PowerShell comes with Server 2008 now, and is installable on anything after XP, it's becoming less of an issue.

If you have full control over the servers which your scripts will run on, I'd recommend going with PowerShell.

Answer 3

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