Getting Acquainted with Variables

Getting Acquainted with Variables

In command-line scripting, what we commonly call variables are more properly called environment variables. Environment variables can come from many sources. Some variables are built into the operating system or derived from the system hardware during startup. These variables, called built-in system variables, are available to all Windows processes regardless of whether anyone is logged on interactively. System variables can also come from the Windows Registry. Other variables are set during logon and are called built-in user variables. The built-in user variables available are the same, no matter who is logged on to the computer. As you might expect, they are valid only during an actual logon session, that is, when a user is logged on.

You can see a listing of all the variables known in the current instance of the command shell by typing set at the prompt. In addition to the normal system and user variables, you can create variables whenever Windows is running, which is exactly what you’ll do when you program in the command shell. You define variables for the current instance of the command shell using the SET command and the following syntax:

set variable_name=variable_value

such as

set working=C:\Work\Data

set value=5

set string="Hello World"

Some variables, including system and user environment variables, have special meaning in the command shell. These variables include path, computername, homedrive, and many other important environment variables. One environment variable that you should learn more about is errorlevel, which tracks the exit code of the most recently used command. If the command executes normally, the error level is zero (0). If an error occurs while executing the command, the error level is set to an appropriate nonzero value. Error values include

• 1  Indicates a general error
• 2  Indicates an execution error, meaning the command failed to execute properly
• –2  Indicates a math error, such as when you create a number that is too large for the command shell to handle

You can work with the errorlevel variable in several ways. You can check for a specific error condition, such as

if "%ERRORLEVEL%"=="2" echo "An error occurred!"

Or, you can use the following special syntax and check for a condition equal to or greater than the specified exit code:

if errorlevel 2 echo "An error occurred!"

Note

You’ll see more on errorlevel and if statements later in the chapter in the section titled “Using Conditional Statements.”

When you are finished working with variables, it’s good form to dispose of them. You do this to free memory used by the variable and prevent problems or unexpected results if you accidentally refer to the variable in the future. To clear out a variable, you simply set the variable equal to nothing, such as

set working=

Now the variable is cleared out of memory and is no longer available.

Using Variables in CMD Scripts

Using Variables in Scripts

In scripts, you’ll use variables to store values as you perform various types of operations. Unlike most programming languages, you cannot declare a variable in a command-line script without simultaneously assigning it a value. This makes a certain amount of sense because from a practical point of view, there’s no reason to have a variable that contains nothing. The sections that follow discuss key concepts for working with variables, including

• Variable names
• Variable values
• Variable substitution
• Variable scope

Naming Variables

The command shell tracks variable names in the case you use but doesn’t care about the case when you are working with the variable. This means variable names aren’t case-sensitive but are case-aware. Beyond this, very few restrictions apply to variable names and you can use just about any combination of letters, numbers, and characters to form the variable name. In fact, all the following variable names are technically valid:

2six

85

!

?

But why in the world you’d want to use such horrendous variable names is beyond me. With that said, how should you name your variables? Well, the most important rule to keep in mind is that variable names should be descriptive. Use names such as

System-name

CurrentStats

mergetotal

Net_Address

These descriptive variable names are helpful when you or someone else needs to modify the script. And notice that there are many ways to create multiple- word variable names. Although you are free to use whatever style you like, most programmers format multiword variable names with a lowercase initial letter on the first word and uppercase initial letter on each subsequent word. Why? The reason is simple: this is a standard naming convention. Following this convention, the variable names used previously are created as

systemName

currentStats

mergeTotal

netAddress

Note

Keep in mind that the command shell doesn’t care about the case. Variable names are case-aware but they’re not case-sensitive. This means that you could refer to the systemName variable as SYSTEMNAME, systemname, or even sYStemNAMe.

Setting Variable Values

As discussed previously, you define new variables using the following syntax:

set variable_name=variable_value

where variable_name is the variable name and variable_value is its related value. Spaces are valid in both names and values. So only use spaces around the equal sign (=) if you want the name and/or the value to include these spaces.

Unlike many programming languages, the command shell doesn’t differentiate between various data types. All variables are stored as character strings. This is true even when you set the variable value to a number. Thus, the following values are stored as strings:

Current status:

311

"Error!"

12.75

using commands such as:

set varA=Current status:

set varB=311

set varC="Error!"

set varD=12.75

Don’t forget that some characters are reserved in the command line, including @ < > & | ^. Before you use these characters, you must escape them with the caret symbol (^) as discussed in Chapter 2, “Getting the Most from the Command Line”—no matter where they occur in the variable value. For example, to set these literal string values:

2 & 3 = 5

2^3

you must set the variable value as follows:

2 ^& 3 = 5

2^^3

using statements such as

set example1=2 ^& 3 = 5

set example3=2^^3

Note

An odd thing happens if you try to echo the example values. Instead of the equations you expect, you get either an error or an odd value. What is happening here is that when you echo the value, the special characters are reparsed. If you want to set a variable to a value that includes a special character and also be able to display this value to users, you must use three escape codes, meaning that you would use set example1=2 ^^^& 3 = 5 or set example2=2^^^^3. This is necessary because the value is double parsed (once when the value is set and once when the value is displayed).

Substituting Variable Values

Variables wouldn’t be very useful if the only way you could access them was with the SET command. Fortunately, you can access variable values in other ways. One of these ways is to use variable substitution to compare a variable name with its actual value. You saw this type of substitution at work in the following line from a previous example in this chapter:

if "%ERRORLEVEL%"=="2" echo "An error occurred!"

Here, you are determining whether the value of the errorlevel environment variable is equal to 2 and, if it is, you display text stating that an error occurred. The percent signs surrounding the variable name tell the command shell you are referencing a variable. Without these percent signs, Windows would perform a literal comparison of “ERRORLEVEL” and “2”. Note also the use of quotation marks in the example. The quotation marks ensure an exact comparison of string values.

Another way to use substitution is to replace a variable name with its actual value. For example, you might want to create a script that can be run on different computers, so rather than hard-coding the path to the system root directory as C:\Windows, you could use the environment variable systemroot, which references the system root of the particular computer being accessed. With this in mind, you use the following line of code in your script:

cd %SYSTEMROOT%\System32

instead of this line of code:

cd C:\Windows\System32

You can also use variable substitution when you are assigning variable values, such as

systemPath=%SystemRoot%\System32

Variable substitution can be quite powerful. Consider the code snippet shown as Listing 3-3.

Listing 3-3: Sample Script Header

@echo off

@if not "%OS%"=="Windows_NT" goto :EXIT

@if "%1"=="" (set INFO=echo && set SEXIT=1) else (set INFO=rem && 

set SEXIT=0)






%INFO% ************************

%INFO% Script: SystemInfo.bat

%INFO% Creation Date: 2/2/2004

%INFO% Last Modified: 3/15/2004

%INFO% Author: William R. Stanek

%INFO% E-mail: williamstanek@aol.com

%INFO% ************************

%INFO% Description: Displays system configuration information

%INFO%              Including system name, IP configuration

%INFO%              and Windows version.

%INFO% ************************

%INFO% Files: Stores output in c:\current-sys.txt.

%INFO% ************************






@if "%SEXIT%"=="1" goto :EXIT






@title "Configure Scheduling..."

cls

color 07

Listing 3-3 is a standard header that I use in some of my scripts. The first if statement checks to see what operating system is running. If it is Windows 2000 or later, meaning Windows 2000, Windows XP, or Windows Server 2003, the script continues execution. Otherwise a goto subroutine is called. The second if statement checks the value of the first argument passed in to the script. If the script is called with no arguments, instances of %INFO% are replaced with echo, which writes the script documentation to the output. If the script is called with one or more arguments, instances of %INFO% are replaced with rem to designate that the associated lines are comments.

Note

Don’t worry if you don’t understand the example completely. You’ll learn all about conditional execution and subroutines later in the chapter in the sections titled, “Command-Line Selection Statements” and “Creating Subroutines and Procedures.”

Localizing Variable Scope

Changes you make to variables in the command shell using set are localized, meaning that they apply only to the current command shell instance or to command shells started within the current command shell (nested command shells) and are not available to other system processes. Further, once you exit the command shell in which variables were created, the variables no longer exist.

Sometimes you may want to limit the scope of variables even further than their current command-shell process. To do this, you can create a local scope within a script that ensures any variable changes are localized to that specific area within the script. Later, you can end the local scope and restore the environment to its original settings.

You can mark the start of a local scope within a script using the SETLOCAL command and then end the local scope with an ENDLOCAL command. Several events take place when you use these commands. The call to SETLOCAL creates a snapshot of the environment. Any changes you make within the scope are then localized and discarded when you call ENDLOCAL. An example using SETLOCAL and ENDLOCAL follows:

@echo off

set sysCount=0

set deviceCount=0

rem Start localization

setlocal

set sysCount=5

set deviceCount=5

echo Local count: %sysCount% system edits ^& %deviceCount% device 

checks

endlocal






echo Count: %sysCount% system edits ^& %deviceCount% device checks

The output of the script is

Local count: 5 system edits & 5 device checks

Count: 0 system edits & 0 device checks

As you can see, local scopes behave much like nested command shells. As with the nested command shells, you can nest several layers of localization. And though each layer inherits the environment settings of its parent, any changes in the nested layer are not reflected in the parent environment.