Windows Script Host (WSH) has made its mark by leveraging outside components. Noteworthy WSH scripts often use external tools, such as Windows Management Instrumentation (WMI), Active Directory Service Interfaces (ADSI), and other COM-enabled libraries and applications. One particularly large and useful family of specialty tools is the traditional command-line tools. Command-line tools are ready-made for administrators and are often useful when tools such as WMI aren't available.
However, leveraging command-line tools in WSH scripts is difficult. Although WSH's WshShell object lets you access command-line tools through its Run method, using this method has two significant problems. The first problem is that many of the command-line tools have console-dependent behavior and can perform erratically if they execute in the wrong command processor. The second problem is more significant: The Run method doesn't provide a way to capture output. Although the new WshShell Exec method in WSH 5.6 returns command-line data, this method has limitations. It's complex to use because you must monitor streams. If you use WScript, the Exec method requires a visible console window, and a window pops up every time the method executes a command. Another limitation is that not everyone has WSH 5.6 installed.
To resolve these problems without repeating code every time I want to use a console tool in WSH, I use a generic command-line wrapper. The command-line wrapper provides an easy way to use command-line tools in WSH scripts. It captures the output from commands, doesn't require a visible console window, and works on all modern versions of Windows, even without WSH 5.6.
You can use the command-line wrapper in any WSH script. Although I wrote it in VBScript, you can even use it in JScript code through a .wsf file. Let's take a detailed look at how the command-line wrapper opens the correct command processor, runs the tool, captures all the command output, then sends that output to WSH.
Opening the Correct Command Processor
As I mentioned previously, command-line tools can run erratically if the wrong command processor runs them. In Windows XP, Windows 2000, and Windows NT 4.0, you typically want to use cmd.exe, the full 32-bit command-line interface. In Windows Me and Windows 9x, you have to use command.com. To ensure that the script uses the correct command processor, the command-line wrapper uses %COMSPEC%, a system-provided environment variable that specifies the name of the default processor.
The command processor must exit when it finishes. For cmd.exe, command.com, and all other standard processors, the /c switch forces the processor to close. To open the correct command window on the local system, then close the command window after the tool has run, the command-line wrapper uses the code
%COMSPEC% /c cmd
where cmd is the command that launches the command-line tool. So, for example, if you want to run the Ipconfig command-line tool, the code would be
%COMSPEC% /c ipconfig
Ipconfig is a useful command-line tool in WSH scripts. Using other tools such as WMI to obtain a PC's IP configuration data requires many lines of code because of possible multiple instances of addresses, gateways, subnet masks, and other key information. Ipconfig, which is available on XP, Win2K, NT 4.0, Windows Me, and Win98 (and even Win95 with the Microsoft Windows 95 Resource Kit), acquires this data in one step.
Running the Tool
At this point, you have the code in place that opens and closes the command processor. Now you need to add code that tells the VBScript scripting engine to run the command-line tool. You can use WshShell's Run method, which has the syntax
object.Run(strCommand,
[intWindowStyle],
[bWaitOnReturn])
where strCommand is the command to run (in the command-line wrapper's case, the command that launches the command-line tool). The intWindowStyle argument tells the scripting engine what kind of window (if any) to display when running the command. The command-line wrapper specifies the value 0 for intWindowStyle so that the scripting engine hides the window. The bWaitOnReturn argument tells the scripting engine whether to wait until the command finishes running before continuing. For bWaitOnReturn, the command-line wrapper specifies the True value so that the scripting engine won't proceed to the next line of code until the command finishes running. Thus, at this point, the command-line wrapper looks like
cmd = "ipconfig"
Set sh = CreateObject _("WScript.Shell")
sh.Run "%COMSPEC% /c cmd",
0, true
Capturing All the Command Output
The next step is to add code that captures all the tool's output. Capturing and redirecting standard output is simple. If you have experience with writing batch files or running commands from the command line, you're probably familiar with using the > redirection symbol to send command output to a file. However, with command output, you can't just redirect the output to a standard file. You need to consider what happens if the command output doesn't come back as standard output. If the command process can't find the command-line tool or the tool encounters problems while running, the tool usually sends error output to a channel called the command error output stream. You'll lose the error output if you don't redirect the error output stream to a file.
When you use the > redirection symbol, you can specify numbers that correspond to the standard output stream and the error output stream. Preceding the > redirection symbol with the number 1 specifies the standard output stream, whereas preceding the > redirection symbol with the number 2 specifies the error output stream. (If you don't preface the > redirection symbol with any number, the output goes to the standard output stream by default.) A good practice is to redirect both the standard output stream and error output stream to temporary files to avoid accidentally overwriting other files and to easily erase the file when you're finished using it. So, the command-line wrapper uses the code
%COMSPEC% /c cmd
2>err.tmp 1>out.tmp
to redirect the tool's standard output to the temporary file named out.tmp and any error messages to the temporary file named err.tmp. Thus, the Run method now looks like
cmd = "ipconfig"
Set sh = _ CreateObject("WScript.Shell")
sh.Run "%COMSPEC% /c" & _
cmd & "2>err.tmp 1>out.tmp",
0, true