Command-shell scripting is one of those technologies that Microsoft has tried hard to leave behind in the bin of legacy software. Unsexy but highly effective, command-shell scripting is a DOS-era holdover that's too useful to ever dispose of. The command-shell syntax is easy to learn, and because the syntax is built into every Microsoft OS, command-shell scripts are easy to deploy. In addition, command-line tools that command-shell scripts use regularly are equally easy to install. They typically require simple xcopy-style deployment to the target system with no need to perform any additional installation or registration step. This combination of factors provides a quick turnaround for administrators who need to quickly and effectively create scripts to automate regular administrative tasks.
However, command-shell scripts—with their limited text-oriented input and output capabilities—never fit into Microsoft's picture of Windows automated administration. For several valid reasons, Microsoft has clearly designated VBScript as the replacement for command-shell scripts. Microsoft first pushed VBScript (and later its driving shell, Windows Script Host—WSH) and a plethora of COM objects as the scripting tool of choice. To be sure, VBScript is a more powerful alternative to simple command-shell scripts. The language advantages are numerous, including the fact that VBScript is integrated with the Windows UI whereas command-shell scripting is text-oriented. However, script writing involves more than the capabilities of the language—and scripting with VBScript and WSH has one big disadvantage: By itself, VBScript provides precious little functionality.
The VBScript Learning Curve
To access system and network resources, VBScript typically requires a variety of COM objects. This dependency on external COM libraries has prevented VBScript and WSH from supplanting command-shell scripts. The VBScript syntax is easy to learn and well within the capabilities of end users and network administrators to master and use. Unfortunately, that statement isn't true of the myriad COM objects that you must find and understand if you want to do anything useful with VBScript.
For example, if you want to add user accounts, VBScript alone can't manage it. Adding the Active Directory Service Interfaces (ADSI) COM object enables this capability. However, to use the ADSI COM object, you must understand the ADSI object's properties and methods. And that's nothing compared with the daunting complexity of Windows Management Instrumentation (WMI), which you need to access all the really important system settings. The WMI object with its powerful (albeit convoluted) namespace lets you display and change process, CPU, disk, and performance information. But you first need to know which COM object you need for each task, which can be a tough assignment in its own right.
Such complexities reveal Microsoft's deeply ingrained developer orientation. Microsoft assumes that all users and administrators are programmers. But that's not the case—which is why VBScript and WSH won't replace command-shell scripting anytime soon. Finding and mastering the complexities of dozens of COM objects presents too steep a learning curve—one that you must repeat for each new task that requires an additional COM object. Many administrators find that the time required to pick up and use VBScript and WSH to perform useful administrative tasks is just too great—a hurdle command-shell scripts don't present. Just for the record, VBScript and WSH are typically my first choice for generating scripts, but many times I still find command-shell scripts quicker to write and easier to implement.
Command-Shell Scripting's Demise Exaggerated
Even Microsoft begrudgingly has acknowledged the continuing popularity of command-shell scripting by adding 30 additional command-line functions to the upcoming version of Windows .NET Server (Win.NET Server) 2003. So—despite command-shell scripting often being regarded as a step-child to VBScript and WSH—command-shell scripting won't go away anytime soon and will be supported fully in the foreseeable future releases of Windows.
End of Article
