Scripts and Script Execution
Scripts are simple text
files that you create using Notepad or some other text editor. You can
use a word processor such as WordPad to create scripts, but you must
make sure that you save these files using the program’s Text Only
document type. For VBScript, a good alternative to Notepad is the editor
that comes with either Visual Basic or any program that supports VBA
(such as the Office suite). Just remember that VBScript is a subset of
VBA (which is, in turn, a subset of Visual Basic), so it does not
support all objects and features.
In a web page, you use the <script> tag to specify the scripting language you’re using, as in this example:
With the Windows Script Host, the script file’s extension specifies the scripting language:
For VBScript, save your text files using the .vbs extension (which is registered as the following file type: VBScript Script File).
As described in the next
three sections, you have three ways to run your scripts: by launching
the script files directly, by using WSscript.exe, or by using CScript.exe.
Running Script Files Directly
The easiest way to run a script from within Windows is to launch the .vbs or .js
file directly. That is, you either double-click the file in Windows
Explorer or type the file’s path and name in the Run dialog box. Note,
however, that this technique does not work at the Command Prompt. For
that, you need to use the CScript program described a bit later.
Using WScript for Windows-Based Scripts
The .vbs and .js file types have an open method that’s associated with WScript (WScript.exe), which is the Windows-based front end for the Windows Script Host. In other words, launching a script file named MyScript.vbs is equivalent to entering the following command in the Run dialog box:
The WScript host also defines several parameters that you can use to control how the script executes. Here’s the full syntax:
WSCRIPT filename arguments //B //D //E:engine //H:host //I //Job:xxxx //S //T:ss //X
|filename||Specifies the filename, including the path of the script file, if necessary.|
|arguments||Specifies optional arguments required by the script. An argument is a data value that the script uses as part of its procedures or calculations.|
|//B||Runs the script in batch mode, which means script errors and Echo method output lines are suppressed. |
Active Debugging. If an error occurs, the script is loaded into the
Microsoft Script Debugger (if it’s installed) and the offending
statement is highlighted.|
|//E:engine||Executes the script using the specified scripting engine, which is the scripting language to use when running the script.|
|//H:host||Specifies the default scripting host. For host, use either CScript or WScript.|
|//I||Runs the script in interactive mode, which displays script errors and Echo method output lines.|
|//Job:xxxx||In a script file that contains multiple jobs, executes only the job with idxxxx. attribute equal to |
|//S||Saves the specified WScript arguments as the default for the current user; uses the following Registry key to save the settings:
HKCU\Software\Microsoft\Windows Script Host\Settings
|//TT:ss||Specifies the maximum time in seconds (ss) that the script can run before it shuts down automatically.|
|//X||Executes the entire script in the Microsoft Script Debugger (if it’s installed).|
For example, the following command runs MyScript.vbs in batch mode with a 60-second maximum execution time:
wscript myscript.vbs //B //TT:60
A script job
is a section of code that performs a specific task or set of tasks.
Most script files contain a single job. However, it’s possible to create
a script file with multiple jobs. To do this, first surround the code
for each job with the <script> and </script> tags, and then surround those with the <job> and </job> tags. In the <job> tag, include the id attribute and set it to a unique value that identifies the job. Finally, surround all the jobs with the <package> and </package> tags. Here’s an example:
WScript.Echo "This is Job A."
WScript.Echo "This is Job B."
Save the file using the .wsf (Windows Script File) extension.
If you write a lot
of scripts, the Microsoft Script Debugger is an excellent programming
tool. If there’s a problem with a script, the debugger can help you
pinpoint its location. For example, the debugger enables you to step
through the script’s execution one statement at a time. If you don’t
have the Microsoft Script Debugger, you can download a copy from http://msdn.microsoft.com/en-us/library/ms950396.aspx.
Using CScript for Command-Line Scripts
The Windows Script Host has a second host front-end application called CScript (CScript.exe),
which enables you to run scripts from the command line. In its simplest
form, you launch CScript and use the name of the script file (and its
path, if required) as a parameter, as in this example:
The Windows Script Host displays the following banner and then executes the script:
Microsoft (R) Windows Script Host Version 5.8 for Windows
Copyright (C) Microsoft Corporation. All rights reserved.
As with WScript, the CScript host has an extensive set of parameters you can specify:
CSCRIPT filename arguments //B //D //E:engine //H:host //I //Job:xxxx //S //T:ss //X //U //LOGO //NOLOGO
This syntax is almost identical to that of WScript, but adds the following three parameters:
|//LOGO||Displays the Windows Script Host banner at startup|
|//NOLOGO||Hides the Windows Script Host banner at startup|
|//U||Uses Unicode for redirected input/output from the console|
Script Properties and .wsh Files
In the preceding two
sections, you saw that the WScript and CScript hosts have a number of
parameters you can specify when you execute a script. It’s also possible
to set some of these options by using the properties associated with
each script file. To see these properties, right-click a script file and
then click Properties. In the properties sheet that appears, display
the Script tab, shown in Figure 1. You have two options:
Stop Script After Specified Number of Seconds—
If you activate this check box, Windows shuts down the script after it
has run for the number of seconds specified in the associated spin box.
This is useful for scripts that might hang during execution. For
example, a script that attempts to enumerate all the mapped network
drives at startup might hang if the network is unavailable.
Display Logo When Script Executed in Command Console—
As you saw in the previous section, the CScript host displays some
banner text when you run a script at the Command Prompt. If you
deactivate this check box, the Windows Script Host suppresses this
banner (unless you use the //LOGO parameter).
Figure 1. In a script file’s properties sheet, use the Script tab to set some default options for the script.
When you make changes to these properties, the Windows Script Host saves
your settings in a new file that has the same name as the script file,
except with the .wsh (Windows Script Host Settings) extension. For example, if the script file is MyScript.vbs, the settings are stored in MyScript.wsh. These .wsh files are text files organized into sections, much like .ini files. Here’s an example:
To use these settings when running the script, use either WScript or CScript and specify the name of the .wsh file:
Rather than setting
properties for individual scripts, you might prefer to set global
properties that apply to the WScript host itself. Those global settings
then apply to every script that runs using the WScript host. To do this,
run WScript.exe without any parameters. This displays the properties sheet for WScript, which contains only the Script tab shown in Figure 30.1. The settings you choose in the properties sheet are stored in the following Registry key:
HKLM\Software\Microsoft\Windows Script Host\Settings
Running a Script as the Administrator
you run scripts in Windows 7, you may on occasion need to run those
scripts under the auspices of the Administrator account.
When you need to run a
script under the Administrator account, one solution is to first launch
an elevated Command Prompt session.
From the elevated command line, you could then use CScript to launch
the script, as described earlier. That would work, but it’s a bit of a
hassle. If you run a lot of administrator scripts, you’d probably prefer
something a lot more direct.
I’m happy to report that a
much more direct method is available. You can tweak the Windows 7 file
system to display a Run as Administrator command when you right-click a
VBScript file. Click that command, enter your UAC credentials, and your
script runs with administrator privileges.
Here’s what you do:
If you don’t feel like modifying the Registry by hand, there’s a file containing the necessary changes—VBSFile_RunAsAdminisrator.reg—on my website at http://mcfedries.com/Windows7Unleashed/.
Select Start, type regedit, and press Enter. The User Account Control dialog box appears.
Enter your UAC credentials to open the Registry Editor.
Navigate to the following key:
Select Edit, New, Key, type RunAs, and press Enter.
With the new runas key selected, select Edit, New, Key, type Command, and press Enter.
In the Command key, double-click the (Default) to open the Edit String dialog box.
Type the following value and click OK (modify the Windows location if yours is installed somewhere other than C:\Windows):
"C:\Windows\System32\WScript.exe" "%1" %*
Select Edit, New, String Value. The Registry Editor creates a new value in the Layers key.
Type IsolatedCommand and press Enter.
Double-click the entry you just created. The Edit String dialog box appears.
Type the following value and click OK (again, modify the Windows location if yours is installed somewhere other than C:\Windows):
"C:\Windows\System32\WScript.exe" "%1" %*
shows the modified Registry. With these tweaks in place, right-click a
VBScript file and you see the Run as Administrator command, as shown in Figure 3.
Figure 2. The dialog box that’s displayed when you run the script.
Figure 3. Tweaking the Windows 7 Registry to add the Run as Administrator command to the shortcut menu of any VBScript file.