Share via

Tracking Script Progress

  • Article

Microsoft® Windows® 2000 Scripting Guide

System administration scripts typically run without displaying a user interface of any kind. This is due to the nature of many of these scripts. For example, you might have a script that runs at 4 A.M., checks the size of all your event logs, and - if necessary - backs up and clears the logs that are nearly full. Not only would you have little need for a user interface with a script like this, but, even if you provided one, no one would be present to view it.

Many scripts have no need to display a user interface for other reasons as well:

  • Users are not distracted by a user interface. Scripts can run in the background, and users can continue doing their work without interruption.

  • Users cannot easily stop a script from running. Without a user interface, the only way to stop a script from running is to terminate the script process.

  • Many scripts complete their tasks so quickly that a user interface would be superfluous. For example, a script that does nothing but verify that a particular service is still running can probably complete its job in one or two seconds. There is little need to construct a user interface for a script that will display that interface for only a second or two.

On the other hand, at times the lack of a user interface can be a disadvantage:

  • It is difficult to tell what scripts, if any, are running on a computer. Even Task Manager is of little use in this regard: Task Manager will report how many instances of WScript or CScript are running on a computer, but it cannot tell you which scripts are running in those instances.

  • It is impossible to tell how much progress, if any, a script is making. In fact, it is sometimes difficult to tell whether a script is even running or if it has become hung. For example, Task Manager reports how much CPU time a script is using, but even 0 percent does not mean a script has stopped responding; it might mean the script is waiting for data to arrive over the network.

In an enterprise setting, it is useful to know which scripts are running on a computer. For example, you might have a script that copies events from an event log. Depending on how the script has been written, it might take an hour or more to complete its task. If so, you probably do not want to inadvertently start a second copy of the script.

Likewise, if the script has stopped responding, you need to know that as soon as possible. That way, you can terminate the process and restart the script. Otherwise, you might wait for over an hour only to discover that the script has failed and must be restarted.

Although scripting languages provide little in the way of user interface elements, you can still track script progress either by taking advantage of Internet Explorer or by using the standard output capabilities of CScript.

Tracking Relative Progress

It is difficult to track absolute script progress - that is, to report that a script is 63 percent complete. Although this is possible in some cases, usually too many variables are involved to enable you to accurately predict when a script will finish. For example, anything from increased network traffic to a new process starting on the local computer can increase the amount of time required to complete a script.

Because of this, the progress indicators used in this chapter do one of two things: They simply note that a script is currently running, or they report relative progress. For example, the progress indicator might note that a connection is being made to a remote computer; after the connection is made, the indicator might note that data is being retrieved. However, no effort is made to estimate how long it will be before data retrieval is complete. Although it is possible to create progress indicators that do this, the code required for the progress indicator would be longer and more complex than the code required to carry out the primary function of the script.