Error Trapping and Capturing Third-Party Output in WSH - Capturing Third-Party Output
(Page 4 of 4 )
Now that we know how to log events in our script in several different ways, let’s take a look at some things worth logging. One of the most useful purposes for logging in a script is to monitor the activity of a third-party program.
Perhaps you’re writing a script that runs every hour and tests the TCP/IP connectivity of every computer on your network. A simple ping test is all that is required. It seems logical that you would be able to run ping.exe from within your script, but how can you capture its output to determine whether or not it was successful?
This is where standard streams come into play. In my last article, “Handling User Input in WSH,” we learned how to use two of the standard streams, standard input (StdIn) and standard output (StdOut). We’re going to make use of both of those in this segment as well but I am also going to show you the third and final standard stream, standard error (StdErr).
Before we get too far ahead of ourselves, let’s take a quick look at how to run third-party programs in WSH. The WshShell object provides us with the Run method and the Exec method. Both are able to start applications and execute command lines directly.
The Run method can be compared to running an application from the Run dialog box. The Exec method is the same as executing a command line at the command prompt.
When executing command lines there is a slight difference between the two: the Run method will create a separate instance, or window, for the running process while the Exec method will run within the same instance. For this reason we will use the Exec method so that output is directed to the same window in which our script is running.
object.Run strCommand[, intWindowStyle][, bWaitOnReturn]
object.Exec strCommand
The Exec method accepts a single string attribute that is the command line to be executed. It returns a WshShellExec object. This object has a property for each of the three standard data streams. Each of these properties returns a read-only text string.
First, let’s take a look at how to actually execute a command line. This particular script is going to ping the localhost address. The script should not fail if you have a network adapter installed.
strCommand = "ping.exe 127.0.0.1"
Set WshShell = CreateObject("WScript.Shell")
Set WshShellExec = WshShell.Exec(strCommand)
Executing this code snippet will not output anything on the screen even though the ping command is executed. That’s because its output is sent to the WshShellExec object’s StdOut stream. You can retrieve the information by adding the following lines.
sOutput = WshShellExec.StdOut.ReadAll
Wscript.StdOut.Write sOutput
This code simply reads the WshShellExec’s StdOut stream into a string variable and then writes it to the Wscript object’s StdOut stream which writes it to the command window.
If we use this example, we can build a basic error-handling routine.
Const WshFinished = 1
Const WshFailed = 2
strCommand = "ping.exe 127.0.0.1"
Set WshShell = CreateObject("WScript.Shell")
Set WshShellExec = WshShell.Exec(strCommand)
Select Case WshShellExec.Status
Case WshFinished
sOutput = WshShellExec.StdOut.ReadAll
Case WshFailed
sOutput = WshShellExec.StdErr.ReadAll
End Select
WScript.StdOut.Write sOutput
In this code example we check the status of the WshShellExec object. If it was successful, we grab the standard output stream to get the command’s output. If it failed, we instead turn to the standard error object to see what went wrong.
We could easily use the information in sOutput to generate log entries. You can see now how these two ideas work hand-in-hand.
I’ve given you some ways to write better, more professional code. I hope that you’ll take the time to implement them into your own scripts. Proper error-handling can be very useful if you ever have to provide support for your scripts. Good luck writing better scripts. Until next time, keep coding!
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
