Most Windows administrators rely heavily on running commands at the command line to accomplish day-to-day administrative tasks and to automate tedious, repetitive tasks. The best part about such commands is their switches (aka parameters), which let you customize the commands' behavior. The Net Use command, for example, wouldn't be as useful without its /persistent switch, and the Xcopy command would be useless without its many switches.
Many administrators also use VBScript to make their lives easier—if you're reading this, you've probably written a few scripts of your own. But administrators often don't maximize the flexibility of their scripts, because most administrators don't write their scripts to take advantage of command-line switches.
For example, let's assume you've written a script called DisableUser.vbs, which Listing 1 shows, that lets you easily handle employee resignations. The script disables a user account and the user's home directory share while leaving the user's user account and home directory intact for archival and administrative purposes.
Adding Flexibility with Switches
The problem with DisableUser.vbs is that its important values—the user's account name, the name of the server that contains the user's home directory, and the user's domain name—are hard-coded in the script. Before running the script, you need to open it in Notepad, modify those values, and save the revised script. To eliminate having to open and modify the script each time you use it, you can use command-line switches. When your script supports command-line switches, you can launch the script and provide the necessary values at the command line. For example, the command
-u:donj -s:server1 -d:mydomain
launches DisableUser.vbs and passes three values—the account name (donj), the server name (server1), and the domain name (mydomain)—to the script.
The main Windows Script Host (WSH) object, WScript, passes the three command-line parameters to the script. WScript includes a collection named Arguments, which contains one item for each parameter passed to the script. WSH parses the Arguments collection and uses spaces as switch separators. Thus, WSH considers every string of characters that has a space on both ends to be a separate parameter.
Your script can easily access the switches through a For Each...Next statement such as
For Each oArg in WScript.Arguments WScript.Echo oArg
To see how such a loop works, type those four lines into the file C:\test.vbs. Then, open a command-shell window and change to the C directory. Type
wscript test.vbs 1 2 3
on the command line. Press Enter, and you'll see a pop-up dialog box that contains all three switch values: 1, 2, and 3.
To put this capability to use in a batch file, you need to use a Select Case statement to analyze each switch and assign its value to a variable. Listing 2 shows sample code that looks for the -s: and -u: switches and assigns their values to the sServer and sUser variables, respectively.
The code starts with a For Each...Next loop that examines each command-line argument individually. For each argument, the script sets the sSwitch variable to the leftmost three characters of the argument string (e.g., -s:). The LCase() function makes the argument lowercase so that the script treats -s and -S the same. The code sets the sValue variable to the remainder of the argument string (i.e., the switch's value) by assigning to the variable the value of the string minus the first three characters.
Finally, the sample code uses a Select Case construct to analyze each argument and assign each switch's value to the correct script variable. When the argument's first three characters are -s:, the script assigns the switch value portion of the argument to the sServer variable. When the argument's first three characters are -u:, the script assigns the switch value to the sUser variable. The Select Case statement lets you type the command-line switches in any order, just like most command-line tools do.
Handling Omitted Switches
An ideal script would accept command-line switches and use pop-up dialog boxes to prompt you for missing information. Such a script would provide the best of both worlds: command-line switches so that you can easily launch the script and provide the necessary parameter values, and pop-up dialog boxes for any required switches that you've forgotten. Incorporating this capability is easy: Just add a few Do...Loop statements that check for missing values after the For Each...Next loop. Listing 3 shows an example. You'll need to add a Do...Loop construct for each required parameter.
Listing 4 shows a new version of DisableUser.vbs called NewDisableUser.vbs that incorporates both command-line and pop-up dialog capabilities. Callout A in Listing 4 shows the added code. NewDisableUser.vbs includes three command-line switches:
- -s: for the name of the server that contains the user's home directory
- -u: for the user account name
- -d: for the name of the domain in which the user's account is located
This script works in Windows 2000 and Windows NT domains. Note that NewDisableUser.vbs uses Microsoft Active Directory Service Interfaces (ADSI).
As you can see, adding command-line switch capability to your scripts makes them much more flexible. When a script supports command-line switches, you don't have to open and modify the script each time you use it. Instead, you can quickly launch it and provide the necessary information at the command line. And when a script incorporates pop-up dialog boxes that prompt you for missing information, you can even launch it by simply double-clicking the script and providing parameters in the pop-up dialog boxes.