Export (0) Print
Expand All

Stop and Go

By The Microsoft Scripting Guys

Sesame Script

Welcome to Sesame Script, the column for beginning script writers. The goal of this column is to teach the very basics of Windows scripting for system administration automation. We’ll provide you with the information you’ll need to begin reading and understanding scripts and to start modifying those scripts to suit your own needs. If there’s anything in particular about scripting you’re finding confusing, let us know; you’re probably not alone.

Check the Sesame Script Archives to see past articles.

On This Page

Starting and Stopping Scripts
Running a Script
Startup Options
Stopping Scripts
Bonus: Windows PowerShell
End of the Trail

Starting and Stopping Scripts

A 1200-pound horse can think it can’t turn right just because the rider has shifted his or her weight to the right. On the other hand, a squirrel that comes running out of a tree can make that same 1200-pound horse take off like a shot. Another thing about horses is that they can move using several different gaits: walk, trot, jog, canter, gallop, and so on. On the surface that might not seem unusual, people can walk and jog too. But it really does get more interesting when you’re talking about four legs rather than two. On top of that, not all of these gaits have to do with moving at different speeds, it can just be a matter of moving the four legs differently to get a different type of movement, look, and feel.

Scripts have different gaits too. (How was that for a segue?) There are several different ways of running a script, all of which can result in a little bit different look to the output of the script. This month we’re going to take a look at some of the different ways of running a script and how that impacts the results we see. And of course, we also want to stop this horse before we get too saddle sore, so we’ll also take a look at a couple of different ways to stop a script. And to help you avoid the fate of one of the Scripting Guys who recently almost fell off a horse, we’ll be sure to take it easy so you can hang on for the full ride.

Running a Script

If you haven’t already read our introduction to scripting, Scripting: Your First Steps, you should take a quick peek at that before continuing. If you have read that then you know that you can start a script by opening a command prompt and typing something like this:



cscript test.vbs

You also know that if you simply double-click on a script file such as test.vbs in Windows Explorer you’ll see all of your output in message boxes, like this:

First Script Message Box

What we didn’t explain in that introduction, however, is what’s really happening here: what is cscript, and why does double-clicking produce a different behavior? We also didn’t talk about various options that are available to you when you run a script. (It was just an introduction, after all.) But now that you know the basics we can take you a step farther and show you some additional functionality you might find useful.

Cscript and Wscript

You might be wondering why you have to type cscript before the name of the file (or at least why it’s usually recommended that you type cscript before the name of the file). Cscript is what’s called a script host. The script host is what enables your script to run on the computer. It identifies the scripting language, tracks down the objects requested by the script, and, in general, interprets what’s happening in your script and ensures the computer will understand it. Cscript and Wscript are the two script hosts within the Windows Script Host (WSH) environment.

Okay, that’s not too difficult: you specify cscript so the computer will know how to run the script. But then why is it you can simply double-click on the file and it will still run? And, here’s something we haven’t mentioned yet; you can also simply type test.vbs (or whatever your script name is) at the command prompt without preceding it with cscript and it will still run just fine. How does the computer know what to do with it?

Well, as we noted, Windows ships with two script hosts: Cscript and Wscript. (We’ll explain the differences in a moment.) Unless you specify otherwise, Wscript is the default. When you type the name of a file that ends with a .vbs file extension at a command prompt, Windows automatically uses Wscript to run the script. That’s also why you can simply double-click the filename in Windows Explorer to run it. Windows sees the .vbs extension and automatically runs it using Wscript. If you don’t want to run the script using the Wscript script host but would rather run the script with Cscript, you must specify cscript when you run the script. Otherwise you get the default script host.

Setting the Default Script Host

You might find that you’re running the majority, if not all, of your scripts with cscript. If that’s the case you might want to change your default script host. To do that you type this at the command prompt:



cscript //H:cscript

After running this command, if you type only the name of the script file at the command prompt, the script will run under Cscript rather than Wscript (because CScript is now the default script host). To set the default back to Wscript, simply run this command:



wscript //H:wscript

Of course, even if you’ve changed your default to Cscript, you can still run scripts under Wscript. Simply precede the filename with wscript:



wscript test.vbs

Cscript vs. Wscript

The difference between Cscript and Wscript is that Cscript is the command-line version of the script host and Wscript is the graphical version. This difference isn’t really noticeable unless your script uses the Wscript.Echo command. As you’ve already seen, if you use Cscript your output from a Wscript.Echo statement will, by default, display to the command window; if you use Wscript that output will display in message boxes. Because of this, you need to consider what can happen if you change your default script host to Cscript. For example, what do you think will happen if your default script host is Cscript and you double-click the script file from Windows Explorer? Well, since the output is now going to the command prompt, Windows will open the command window, display the output, and then - here’s the … fun ... part - close the window. In other words, you’ll get a very brief glimpse of a command window that will disappear before you can actually see any of the output. Not very helpful. So be sure to keep this in mind if you decide to change the default script host.

One thing to note is that this difference in display is only with output that uses the Wscript.Echo statement. If you use the MsgBox function a message box will display whether you’re running under Cscript or Wscript; the same is true of the InputBox function.

There are other slight differences between the two, but Wscript.Echo is the most obvious and the one you’re likely to run into most often.

Startup Options

Like most commands, Cscript and Wscript provide online help that show various options you can use when you start a script. To see the help simply type either of the following at a command prompt:



cscript /?
wscript /?

These commands show you the options available to you when you start a script using cscript or wscript, respectively. The output from these two commands is almost identical, with the main difference being that the first will display the help to the command window, while the second will display the output in a message box:

Command Prompt

Message Box

Let’s take a look at a few of these options.

Logo Information

When you run a script, your output will look something like this:



Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

Test Script Output

First you’ll see information about the version of Windows Script Host running on your machine, and then the obligatory copyright information from Microsoft. All right, now that you’ve seen and understand the copyright you probably don’t need to see this every time you run a script. Fortunately, you can suppress this information from the display by starting your script like this:



C:\> cscript test.vbs //nologo

Now when you run your script your output will look like this:



Test Script Output

This option can be especially useful if you’re piping your output to a file. For example, suppose your script will output user names and you want to write this output to a file that you’ll be using later from another script. It would be better to have your text file look like this:



Ken Myer
Pilar Ackerman

than like this:



Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

Ken Myer
Pilar Ackerman

If you’re wondering what we mean by “writing your output to a text file,” type this line at the command prompt:



cscript test.vbs > textfile.txt

You won’t see any output on the screen because this command will send all the output that would have gone to the screen straight into a text file named textfile.txt.

The //nologo option has no effect if you use it with Wscript, since the logo information is displayed only when you use Cscript.

Batch Mode

Another option you might want to take a look at is //B, the batch mode option:



cscript test.vbs //B

When you specify this option, no output will display to the screen. And when we say none, we mean absolutely none. There is a good side to this and a not-so-good side. Let’s take a look at the good side first. Take a look at this script:



Const ForReading = 1
Const ForWriting = 2

Set objFSo = CreateObject("Scripting.FileSystemObject")
Set objFile = objFSO.OpenTextFile("c:\scripts\test.txt", ForReading)

strContents = objFile.ReadAll
objFile.Close

arrLines = Split(strContents, vbCrLf)

Set objFile = objFSO.OpenTextFile("c:\scripts\test.txt", ForWriting)

For i = 0 to UBound(arrLines) - 1
    objFile.WriteLine arrLines(i)
Next

objFile.Close

Wscript.Echo "Line has been deleted."

We took this script from a recent Hey, Scripting Guy! article which showed how to delete the last line of a text file, then we added one line to the end: we added a Wscript.Echo statement that tells the user the script has finished and that the line has been deleted from the text file. Without the Wscript.Echo statement, the script will run to completion without any visible indication to the user that anything is happening. By adding this line we simply show the user that yes, the script did indeed run and do something. So if you run this script your command window should look like this:



C:\ >cscript deleteline.vbs
Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

Line has been deleted.

If you run this script again but this time using the //B option, your display will look like this:



C:\Scripts>cscript deleteline.vbs //B

Yes, that’s it. The //B option suppresses all output to the screen; you won’t see anything, not even the logo information. The same is true if you use the //B option with Wscript: no message boxes will be displayed. One case in which this can be useful is if you’re running logon scripts and you don’t want anything to display to the user.

One thing to watch out for when using this option is that not only does it hide the output from your script, but it hides error information too. If you’re familiar with the On Error Resume Next statement you know that this statement will bypass errors and continue running a script. (If you’re not familiar with the On Error Resume Next statement, see the Sesame Script article Introduction to Error Handling.) However, On Error Resume Next works only on runtime errors. Plus, as we said, when a script using this statement runs into an error it just ignores it and continues to run to the end of the script. When you use the //B option, no error messages are displayed, including basic syntax errors, and the script will stop on an error. So it will appear that your script ran even if it didn’t, and you’ll have no idea why until you run the script without the //B option.

Time-Out

We mentioned at the beginning of this article that we’d also talk about stopping scripts. One way to do this is to use the //T command-line option to stop the script after a specified number of seconds. For example, suppose we have a script that looks like this:



x = 1
Do Until x = 2
    Wscript.Echo x
Loop

This script assigns the value 1 to the variable x. The Do Until statement says that we want to perform all the script code in between the Do Until statement and the Loop statement until x = 2. That means until the variable x gets a value of 2, we want the script to continue to echo the value of x. As you can see, we never change the value of x to 2, so the script will run forever and you’ll get an endless output of 1s. However, you can tell this script to end after 5 seconds by starting it with the following command:



cscript test.vbs //T:5

After five seconds the script will automatically end and this message will be displayed:



Script execution time was exceeded on script "C:\test.vbs".
Script execution was terminated.

This option can be useful when you’re testing scripts that return a large amount of data, such as retrieving information from a large database, and you want to automatically end the script if it hasn’t completed after a certain amount of time.

Stopping Scripts

We just showed you one way of ending a script, using the //T option, something we demonstrated by showing you a script that would run forever if you let it. Every once in a while you might end up with a script like that unintentionally, which means you didn’t plan for the script to run forever or even for the 20 minutes it’s been running so far; because of that you never specified the //T option when you started it. The simplest way to stop a script that seems to be stuck is the good-old Ctrl+C key combination. Just press Ctrl+C from within the command window and that immediately will stop a script started from that window.

That is, of course, if you’re running the script under Cscript. When you start a script under Wscript, there’s no command prompt waiting around for the script to finish. Even if you started the script from the command prompt, Wscript just starts the script and then returns. In that case, Ctrl+C won’t do any good because Ctrl+C is designed to interrupt the process running in the command window. To stop a script running under Wscript, you need to stop the process in Windows Task Manager. Open Task Manager (right-click the taskbar and select Task Manager, or type taskmgr in the Run dialog box). On the Processes tab select wscript.exe and press End Process.

You can also stop a script from within the script. You can do this by using the Wscript.Quit statement. Try the following script:



Wscript.Echo "line 1"
Wscript.Quit
Wscript.Echo "line 2"

This script will echo the text “line 1” but it will never echo “line 2” because we stopped the script before it got to the second Echo statement. One use of the Wscript.Quit statement is in debugging. You can check the syntax of a script without actually running it by putting Wscript.Quit at the top of your script. When you try to run a script, the first thing that happens is that the code is checked for incorrect syntax, such as an If statement that’s missing an End If. After that the script will try to run. So if you put a Wscript.Quit statement at the top of your script, the script syntax will be checked, but then the Wscript.Quit statement will execute, the script will end, and none of the other script code will ever run.

More Information

For more information on Windows Script Host, Cscript and Wscript see the WSH Primer in the Microsoft Windows 2000 Scripting Guide.

Bonus: Windows PowerShell

The Scripting Guys are in the process of putting together Windows PowerShell Week. This is a week of webcasts - one webcast a day for five days - introducing you to Windows PowerShell, the new command shell from Microsoft. Because we’re thinking about Windows PowerShell right now, we thought we’d throw in a little bonus information here on how to run a Windows PowerShell script.

You can tell a file is a Windows PowerShell script by the fact that is has a .ps1 extension. Running scripts in Windows PowerShell can be a little tricky because there is some added security built in. One security feature is that you can’t run a Windows PowerShell script by double-clicking on it. If you double-click on a .ps1 file, by default this will simply open the file in Notepad. You must run the file from the command prompt.

The second big security thing to know about is that Windows PowerShell contains an execution policy that, by default, restricts the running of scripts. You can check the execution policy by running the following cmdlet in Windows PowerShell:



Get-ExecutionPolicy

There are four execution policies available in Windows PowerShell. To determine which one will allow you safe access to scripts, run the following command:



Get-Help about_signing

Scroll up to find the section “PowerShell Execution Policies.” When you’ve determined which execution policy you need to run, use the Set-ExecutionPolicy cmdlet to set the execution policy.

You can run a Windows PowerShell script by opening Windows PowerShell and typing the name of the script, including the full path, at the command prompt. You can also run a Windows PowerShell script from a standard Command Prompt window by typing a command like this:



powershell C:\Scripts\test.ps1

You might expect the Windows PowerShell window to appear when you do this, but it doesn’t. Instead Windows PowerShell simply takes over the command window. When the script completes you get your regular command prompt back.

One other option is to run a Windows PowerShell script from the Run dialog box. This process is described in this Hey, Scripting Guy! article.

More Information

For more on Windows PowerShell, visit Scripting with Windows PowerShell on the Script Center, and tune in to see the Windows PowerShell Week webcasts November 6 - 10, 2006.

End of the Trail

That’s about it. If you’re waiting for the story about how the Scripting Guy almost fell off a horse, well, it’s not that interesting. The horse was loping along and something just sort of went wrong. The Scripting Guy managed to stay on and finish out the ride. A more interesting story is that this same Scripting Guy once got dragged by a horse. But you know the old saying, “if you fall off a horse get right back on.” That must be why the Scripting Guys continue to come to work every day.


Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft