Input
Microsoft® Windows® 2000 Scripting Guide
« Previous | Next »
The script in Listing 2.12 is designed for an organization in which the computing infrastructure is not expected to change. Needless to say, a static infrastructure such as this is the exception rather than the rule; most organizations have a more dynamic environment. Although there might be only three servers (atl-dc-01, atl-dc-02, atl-dc-03) that need monitoring today, there is no guarantee that only those three servers will need monitoring tomorrow.
Because of that, you might not want to hard-code computer names into a script. Hard-coding items such as computers names can lead to a pair of related problems:
- Lack of flexibility. The script in Listing 2.12 retrieves available disk space information only for the computers atl-dc-01, atl-dc-02, and atl-dc-03. If you need to retrieve free disk space for computer atl-dc-04, you will need to modify the script.
- Frequent updating. The script in Listing 2.12 was designed to retrieve free disk space information for a particular set of computers (for example, all the domain controllers in a particular location). Each time a new domain controller is added, or each time an existing domain controller is retired, the script will need to be updated. If this is the only script used in your organization, this might not pose much of a problem. If you use scores of scripts in your organization, however, you are likely to waste more time modifying scripts than you save by using those scripts in the first place.
There are a number of ways to enter information, such as server names, into a script. (For more information about these methods, see "Creating Enterprise Scripts" in this book.) Perhaps the easiest way is to have the user specify this information as command-line arguments each time the script is run.
An argument (also known as a parameter) is information supplied along with the command that actually runs the script. For example, suppose you typically start a script by typing the following at the command line:
cscript FreeDiskSpace.vbs
An argument is any information added to the end of that command. For example, this command has three arguments, one for each computer name:
cscript FreeDiskSpace.vbs atl-dc-01 atl-dc-02 atl-dc-03
In addition to supplying arguments, you must include code in the script that makes use of those arguments. This type of coding is covered in detail in the "WSH Primer" chapter of this book. A simple example is also shown in Listing 2.13. In line 9 of this script, a For Each loop is established to iterate through the set of arguments supplied when the script was started. In this script, each argument is successively assigned to the variable Computer and then used to connect to the WMI service on that computer (line 10). The first time the For Each loop runs, Computer will be assigned the value atl-dc-01. On subsequent iterations, Computer will be assigned the value atl-dc-02, and then atl-dc-03.
Listing 2.13 Getting User Input
|
|
One benefit of using arguments is that they are automatically placed in a collection (Wscript.Arguments). This makes it easy to iterate through the arguments supplied to a script: You simply set up a For Each loop and iterate through each argument in the collection, exactly as you would iterate through the individual disk drives in a collection of disk drives.
Because arguments are placed in a collection, it is easy to verify how many arguments, if any, were supplied when starting a script. In line 4 of the script, Wscript.Arguments.Count is used to determine how many arguments were supplied (which will equal the number of items in the arguments collection). If Count equals 0, meaning no arguments were supplied, a set of usage instructions is displayed, and the script terminates (using the command WScript.Quit).
 Send us your feedback | « Previous | Next » |
EAN: N/A
Pages: 635