Command-Line Parameters as Input

Many of the administrative utilities you use every day are command-line utilities, such as ipconfig, ping, and tracert. These utilities can all perform different tasks, or different variations of a task, through the use of command-line parameters. For example, ipconfig /all displays IP configuration settings, whereas ipconfig /renew refreshes your computer's DHCP address. You also can write scripts that accept command-line parameters, giving you the ability to create flexible command-line utilities of your own.

Running Command-Line Scripts

Because none of the script file extensions-VBS, VB, SCR, and so forth-are recognized as executable by the Windows command-line processor, you'll need to execute Cscript.exe directly. Tell Cscript which script file you want to execute, and then tack on any of the script's command-line parameters, followed by any Cscript parameters. For example:

Cscript.exe MyScript.vbs /option:yes /value:4 //B

This would execute the VBScript MyScript.vbs, passing it a parameter named option and one named "value," and telling Cscript to suppress any script error messages (see the sidebar, "Power Cscript.exe," later in this chapter for more on Cscript parameters).

Parsing Parameters

The scripting engine includes a built-in parameter-parsing object named WshNamed, which is designed to help your script accept named command-line parameters. Note that this object is also available to graphical scripts executing under WScript, although it's less common to see those scripts using command-line parameters. WshNamed is part of the WshArguments object, which provides top-level access to all command-line arguments passed to the script. I introduced you to objects in VBScript in "What Are Objects?" in Chapter 5.

Suppose you're writing a script that will display basic information about a remote computer. You want the script to accept a command-line parameter named Computer that will provide the computer name to check. You'll execute the script with something like the following:

Cscript.exe GetInfo.vbs /computer:server1

You want the script to run from the command line, so you'll display the output by using WScript.Echo instead of the MsgBox statement.

Getting Remote Machine Information

Listing 6.1 shows what your script might look like.

Listing 6.1. GetInfo.vbs. This script will retrieve basic information about a remote computer.

'Create an arguments object

Dim oArgs

Set oArgs = WScript.Arguments



'Get the named arguments

Dim oNamed

Set oNamed = oArgs.Named



'Get the computer name argument

Dim sComputer

sComputer = oNamed("computer")



'Connect to the remote computer by using WMI

Dim oSystem

Set oSystem = GetObject("winmgmts:{impersonationLevel=" & _

 "impersonate}!//" & sComputer & "/root/cimv2:" & _

 "Win32_ComputerSystem=" & Chr(34) & sComputer & _

 Chr(34))

'Display information

WScript.Echo oSystem.Caption

WScript.Echo oSystem.PrimaryOwnerName

WScript.Echo oSystem.Domain

WScript.Echo oSystem.SystemType

Because this script uses a command-line parameter, or argument, to figure out which computer to connect to, you shouldn't have to make any changes to use it in your environment.

Getting Remote Machine Information-Explained

The script starts by getting a reference to the built-in Arguments object. Notice that you don't need to use CreateObject for this because the object is always loaded when the scripting engine is running.

'Create an arguments object

Dim oArgs

Set oArgs = WScript.Arguments

Next, the script gets the Named object, which is an array of named command-line parameters.

'Get the named arguments

Dim oNamed

Set oNamed = oArgs.Named

With access to the Named object, the script can retrieve the value assigned to the "Computer" named argument. This value is stored in a variable named sComputer.

'Get the computer named argument

Dim sComputer

sComputer = oNamed("computer")

Now the script uses WMI to connect to the designated computer. Notice the use of Chr(34) in this section of the script. This function inserts a quotation mark, which is required around the computer name in the WMI query.

'Connect to the remote computer by using WMI

Dim oSystem

Set oSystem = GetObject("winmgmts:{impersonationLevel=" & _

 "impersonate}!//" & sComputer & "/root/cimv2:" & _

 "Win32_ComputerSystem=" & Chr(34) & sComputer & _

 Chr(34))

For more information on scripting with WMI, start with Chapter 17. For more information on the Chr() function, turn to Chapter 8.

Finally, the script uses the retrieved WMI object to display some information about the computer.

'Display information

WScript.Echo oSystem.Caption

WScript.Echo oSystem.PrimaryOwnerName

WScript.Echo oSystem.Domain

WScript.Echo oSystem.SystemType

Figure 6.6 shows the type of output you should expect at the command line.

Note that I could have chosen not to use the Named object to retrieve the command-line argument in this script. After all, there's only one argument; I could have just as easily used WScript.Arguments(0) to retrieve the first argument. However, I prefer to always use the Named object to access command-line parameters. There are a number of reasons for doing so.

• If an unexpected parameter is included, your script won't accidentally mistake it for a legitimate parameter.

• If your script has multiple parameters, accessing them through Named allows the user to include them in any order, as they can with most Windows command-line utilities.

• Named parameters are easier to work with when maintaining your script. For example, it's easier to tell what Wscript.Arguments.Named("computer") is doing than to try to figure out what WScript.Arguments(0) stands for.

Power Cscript.exe Cscript.exe accepts a number of command-line parameters of its own. To distinguish these from your script's own parameters, Cscript's parameters start with two slashes (//) instead of the usual one. You can see a list of available parameters by running Cscript from a command line with no parameters or script name; some of the most useful parameters are //B. This suppresses script errors and prompts, making your scripts more suitable for use within a batch file or as Task Scheduler jobs. //H:Cscript. This changes the default scripting engine to Cscript, so that when you double-click a VBS file, a command-line window opens and Cscript executes the file instead of WScript. //H:WScript puts things back to normal. //S. Saves your command-line options as the defaults for the current user account. You can use these and other commands to customize your scripting environment. For example, if you find that most of your scripts are of the command-line variety, set Cscript to be the default scripting engine.