VBScript or Perl?

The Windows Sys Admin's Scripting Dilemma

As I was working on Active Directory Cookbook, I had to make a decision that many Windows system administrators face at one point or another: whether to use VBScript or Perl? I'm a long-time Perl guy, but unfortunately, no matter how much I preach the benefits of Perl, the Windows sysadmin community hasn't embraced Perl the way it has been embraced on the Unix side. Ultimately I decided to use VBScript because it is the least common denominator as far as scripting languages go on the Windows platform (besides batch files, of course). I did, however, include Perl examples on my web site so as not to leave out the Perl coders.

I was able to take the easy way out by using both in this case, but most system admins only need one, but which one? I've already stated my preference towards Perl, but I want to outline the pros and cons of each because both languages have their place. You can accomplish most of the basic system admin tasks with either language. For this reason you'll need to look at the other advantages and disadvantages of each language to determine which works best for you.

Advantages of VBScript

No installation required

This is the number one reason VBScript is so widely used. Since you can run VBScript code on any Windows 2000 and later computer without needing to install anything, this makes it much easier to support on a lot of computers.

Popular on Windows

Because VBScript comes out of the box with Windows and was developed by Microsoft, naturally there is better support for it; not only by Microsoft, which documents VBScript extensively on the Microsoft Developer Network (MSDN), but also on other non-Microsoft web sites. Generally, it is much easier to find VBScript examples than Perl examples (for Windows).

Built-in support for COM Automation and WSH

To do much of anything with Windows, you need to use a COM-based API, such as ADSI or WMI. For scripting languages, a subset of COM is supported, which is called the COM automation interface. VBScript can use this directly with the GetObject and CreateObject functions. With Perl, you have to use Win32::OLE module to access COM objects. Here is an example that uses the VBScript GetObject function:

VBScript is a derivative of Visual Basic (VB) so if you know a little VB, it is easy to pick up VBScript.

Disadvantages of VBScript

Limited command-line parsing and GUI support

The built-in support for parsing command-line options and generating graphical interfaces (such as a password prompt) are pretty limited in VBScript.

Awkward and wordy language constructs

I mentioned that VBScript is very readable, but this also makes VBScript wordy in comparison to Perl. Because VBScript treats everything like an object, it often results in awkward language constructs. Perhaps the worst offender is VBScript regular expressions. Here is a simple example that tests if a string contains the letters "www" in it:

strMatch = "www.rallencorp.com"
set objRegEx = New RegExp
with objRegEx
.Pattern = "www"
.IgnoreCase = True
.Global = True
end with
if objRegEx.Test(strMatch) then
WScript.Echo "Matched"
else
WScript.Echo "Did not match"
end if

This is one of the biggest issues with VBScript. Unlike Perl, there is no large VBScript repository where programmers freely contribute and share code in the form of packaged modules or components. There are many repositories that contain sample scripts, but none that I've seen that are on the same scale as CPAN for Perl.

No command-line code execution support

Being able to execute and test code from a command-line is an extremely useful feature of a scripting language. With Perl you can use the -e switch and execute code directly. Here is an example that prints the current time:

C:\> perl -e "print scalar localtime"

There is no counterpart to this in VBScript.

Uncertain future

At this point, it is hard to tell what will become of VBScript. Microsoft did not provide native support for VBScript within the .NET Framework, choosing to support JScript instead. And there are already rumors flying that in the next major release of Windows, codename Longhorn, there will be a new Microsoft Shell (MSH) that will include a new scripting language. If that happens, more than likely VBScript will start to fade away.

Overview of Perl on Windows

Perl has a long history dating back to 1987 when Larry Wall released the first version. Now, an army of dedicated Perl hackers actively maintain Perl, and ports exist for virtually every modern operating system.

Advantages of Perl

Robust

As far as scripting languages go, Perl ranks at or near the top for being the most robust and full-featured.

Extensive module support

If I had to give one reason to choose Perl over VBScript, this would be it. The Comprehensive Perl Archive Network (CPAN) contains an extensive collection of Perl modules that you can use to do just about anything you can think of. As far as Microsoft technologies go, the Win32:: module namespace contains modules for manipulating the registry, generating GUIs, manipulating files, using the Win32 API, and much more. If you've wondered if someone has already written code to do a particular function, odds are it is in a module somewhere in CPAN. Visit http://www.cpan.org/ for more.

Cross-platform

If you work in an environment that has a mix of Microsoft and non-Microsoft operating systems, Perl is your best bet. And depending on what you need to do, you can even write Perl code that works cross-platform.

Actively developed

A large effort has been underway since 1999 to develop the next major version of Perl, Perl 6, which is a complete rewrite of the language.

Disadvantages of Perl

Requires installation

This isn't a big deal, but it is something you have to consider if you want to use Perl across a large number of systems. You can download Perl for free from the ActiveState site. ActiveState provides a number of extras that you can buy if you want to build .NET components, run Perl scripts as services, create executables from Perl scripts, and so on.

Daunting for newcomers

I hear this one quite a bit. Often when people see Perl code for the first time, they write it off as being too complicated to learn without a programming background. It is true that Perl can be extremely hard to read if not written well, but that is due more to the flexibility and capabilities of the language. You can write readable Perl code just as easy as you can write unreadable Perl code.

Limited support by Microsoft

I debated whether to include this as a disadvantage or not, but after several years of developing large Perl applications on Windows, it is apparent to me that Microsoft doesn't like to deal with problems that arise through the use of Perl. Often when I'd find an apparent bug in a Microsoft API, they wouldn't look at the Perl code, but instead required that the error be duplicated using VBScript or VB. It is unlikely you'll find something you can't workaround, but just be aware that if you do encounter a potential bug, you may want to show it to Microsoft in one of their languages to get quicker resolution.

Summary

If you want to get serious about automation in the Windows environment, I recommend using Perl because of its extensive module support and the overall robustness of the language. If you only want to do something quick and dirty or you don't have any programming experience, VBScript is probably your better bet.

As far as other scripting languages go, a case could be made for using JScript because of its integration with the .NET Framework, but I don't find many people using JScript for system admin tasks. I'll leave that for someone else to argue.