It's important to remember the place that batch files
occupy in the hierarchy of automation. A batch represents a fast and
simple way of executing a series of tasks using applications, commands,
and utilities. The batch file possesses basic programming structures and
you can perform amazing tasks at times with those structures, but in
the end, batch files are somewhat limited. Something as simple as a disk
being full or a lack of rights to create a file in a specific location
can cause the batch file to fail. Error trapping in such cases is
difficult because you have to check for error levels from the errant
application, command, or utility and not every one of them supports
output error levels.
|
Real Administrators Use Batch Fiyles
At one time, I thought I
held the title for the number of batch files used for daily activities.
That's until I ran into one network administrator who had more batch
files than I'd ever seen before. He had batch files for every occasion.
In fact, one of the batch files was simply there to track all of the
other batch files (so he didn't reinvent the wheel at some point).
Of course, he didn't
build this huge source of batch files in a day. In fact, he had been
building and refining them over a period of years. This administrator
customized many of the batch files to his way of working with systems
and the network as a whole. In fact, that's the point of batch files.
You can do things your way. Because batch files are simplicity itself,
you can add, remove, and rebuild them as needed.
However, batch files
are important for administrators for another reason. Yet, the
time required to develop a batch file is short and you don't need to
become a programmer to use one. These are the two reasons that most
administrators I've talked with give for using batch files instead of
scripts. Although batch files can't replace scripts or full-fledged
programming languages, over the years I've found that batch files serve
the purpose for most administrator needs.
|
1. Adding Debug Information to Batch Files
Developers of most
applications know how to add debugging statements to their code. The
debugging statements aren't for general use; they simply make it easier
to check the application for flaws. In addition, the debugging
statements make it possible to track program flow and generally help the
developer understand the application better. A batch file can also
include debugging information, even though there aren't specific
statements to perform the task. The following code shows one method you
can use.
@IF NOT DEFINED DEBUG @ECHO OFF
ECHO
@ECHO ON
In this case, the debug trigger is an environment variable named DEBUG. You can set this environment variable to any value desired by using the Set command. Type Set DEBUG=
and press Enter to turn off debugging. The purpose of this debugging
statement is to keep echo on when you're debugging the batch file.
During the debugging cycle, you want to see all of the statements, so
you display them by keeping the echo on. When the batch file runs
normally, the user won't have an environment variable named DEBUG, and the batch file turns off echo so the user doesn't see all of the intervening commands. Using the ECHO command by itself displays the current echo state so you can easily test this technique for yourself.
Notice that the batch file doesn't include anything special for the @ECHO ON
statement. It's bad practice to use conditional statements with
commands that set the system back to a default state. In this case, you
can set echo on without considering the current echo state because
having echo on is the default setting.
You can extend debugging
to other activities. For example, you might want to know the current
value of a variable within the batch file. Because you don't have a
debugging environment that you can rely on to perform such tasks, you'll
need to use other methods with a batch file. Listing 1
shows one technique you can use to extend a batch file to output
debugging information about an internal variable (note that this example
also uses the DEBUG environment variable).
Example 1. Adding Simple Debugging to a Batch File
@ECHO OFF
REM Locate all of the temporary files on your hard drive.
@ECHO Locating temporary files to delete.
FOR /F %%F IN (DelFiles.TXT) DO CALL :GetFile %%F
GOTO :NextStep
REM This is the actual code for handling the temporary file
REM processing.
:GetFile
IF DEFINED DEBUG @ECHO Adding %1 to the list.
Dir %1 /B /S >> DeleteMe.TXT
GOTO :EOF
REM You would normally place the next step of the processing
REM task here.
:NextStep
@ECHO ON
|
This is actually a batch
file within a batch file. The code begins by displaying information to
the user that it's collecting a list of temporary files. At this point,
the user normally waits while the batch file does its job in complete
silence. However, as a developer, you really need to know what's going
on within the batch file. To make this work, you need to execute
multiple commands. Consequently, the batch file calls a label named :GetFile and passes it to the %%F argument.
Now, look at the :GetFile label and you'll see two statements. The first displays the current %%F value when you create an environment variable named DEBUG. However, notice that it's called %1 here, not %%F. Whenever you employ a Call command to pass control to a label within a batch file, you create a new batch file context. As far as the :GetFile label is concerned, it exists in a different batch file from the original that called it. The first batch file passes %%F as an input value, so it appears as %1 to the :GetFile label code. The second statement in :GetFile is the Dir command that locates the files you want to delete based on the file specification.
Notice that the :GetFile section ends with GOTO :EOF, which should end the batch file. It does, in fact, end the :GetFile batch file and returns control to the FOR command that called it. Now the FOR command can process the next file extension in the list. Figure 1 gives you a better idea of how this batch file works with and without DEBUG defined. Notice the batch file doesn't display the file extensions the first time because DEBUG isn't defined yet.
The examples in this
section have only shown a single level of debugging so far. However, you
can create as many levels of debugging as you want by adding some
additional code. Listing 2shows the example in Listing 1 with a second level of debugging added.
Example 2. A Batch File with Multiple Debug Levels Defined
IF NOT DEFINED DEBUG2 @ECHO OFF
REM Set the second level of debugging.
IF DEFINED DEBUG2 SET DEBUG=TRUE
REM Locate all of the temporary files on your hard drive.
@ECHO Locating temporary files to delete.
FOR /F %%F IN (DelFiles.TXT) DO CALL :GetFile %%F
GOTO :NextStep
REM This is the actual code for handling the temporary file
REM processing.
:GetFile
IF DEFINED DEBUG @ECHO Adding %1 to the list.
Dir %1 /B /S >> DeleteMe.TXT
Goto :EOF
REM You would normally place the next step of the processing
REM task here.
:NextStep
REM Always remember to remove additional debugging levels.
IF DEFINED DEBUG2 SET DEBUG=
@ECHO ON
|
The two levels of
debugging for this example are DEBUG and DEBUG2. When you define the
DEBUG2 level, the batch file automatically defines DEBUG for you and
then removes the DEBUG definition when the batch file ends. As shown in
the code, the DEBUG2 level displays all of the batch code as it
executes. Although this display can be handy, as shown in Figure 2,
it can also become quite messy. You don't always need it to locate a
problem in your batch file. In fact, displaying the code can sometimes
hide problems in plain sight.
Many people claim that
batch files don't offer any form of debugging. Admittedly, batch files
don't provide the robust debugging features that full-fledged
programming languages do, but batch files don't require these advanced
levels of debugging either since they normally perform simple tasks.
Using the techniques found in this section, you can provide at least a
modicum of debugging functionality for your batch files.
