Wrappers are batch files that enclose executable programs, usually to customize the environment and/or path, and/or to provide most of a complex command line. Usually they are fairly straight forward, though the reasons for using them may not be. One reason is to allow having a short path, with the directory needed for the specific program added only when needed and only for as long as needed. A typical example is the one that invokes my editor:

 @echo off
 set pcwopath=%path%
 path d:\pcw;%path%
 ed %1 %2
 set path=%pcwopath%
 set pcwopath=

The action is to save the existing path, add the directory of interest to the beginning of the path, invoke the editor, and on termination of the editor, restore the path to what it was before and delete the temporary variable used to hold the original path. Rigorous use of this approach can keep the path length down to just two or three directories.

Wrappers can be placed around clusters of programs that work together, for example, one might add an automatic backup of the file edited to the above:

 @echo off
 set pcwopath=%path%
 path d:\pcw;%path%
 ed %1 %2
 pkzip -a c:\backup\ed %1
 set path=%pcwopath%
 set pcwopath=

The next example illustrates three different points: use of the wrapper to temporarily set environment variables for a command prompt session, use of COMMAND to suspend the batch file, and use of the /e:nnn switch to COMMAND to guarantee that the programs to be run in the session have enough free environment space.

 @echo off
 set lib=c:\fortran\lib
 set include=c:\fortran\include
 set fopath=%path%
 path c:\fortran\bin;c:\fortran\exe;%path%
 command /e:1024
 set path=%fopath%
 set lib=
 set include=
 set fopath=

The idea here is to prepare a custom environment for the FORTRAN editor, compiler, linker, executables, etc., then to generate a command prompt for the session, and clean up afterward. The EXIT command from the command prompt of the secondary command processor closes the session and resumes execution of the batch file. Something of this nature for each language used is pretty much essential for multi language programmers - consider that only the last language installed would have the correct settings for LIB, INCLUDE, etc., and the path would grow quite long if the installation programs for several languages where allowed to have their way. To make this work properly, one must go back through AUTOEXEC.BAT after every installation, find out what was changes, restore the original condition, and build a batch file to install the changes for the sessions. Some programs, notably some languages, create a batch file that makes the changes for you, but these generally assume that you will reboot the computer after the session, since they don't provide a means of undoing the changes. These concepts are by no means limited to language compilers. There is no significance to my use of FORTRAN as an example, it is simply the most recent such installation I have done for a user - it beat out a BASIC interpreter by about half an hour.

Wrappers can get quite complicated if they need to perform complex computations (to create a temporary directory using the date in the name, for instance), but the complications are best addressed in an essay on programs or one on functions, since they are really programs within a batch file.

Batch file wrappers are often used around executables in these environments to establish the drive, directory and path environment for proper execution. There are several things to keep in mind, most of which relate to the instability of the current directory in such multitasking environments as Windows and the uncertainty about where remapped drives point at different times in the process. Consider what happens when one batch file maps a drive to foo and the user switches away to run another that maps it to bar, and then back and forth between the two. Or worse, when something else remaps the drive out from under both, perhaps to an entirely different server. There is also the problem with where a Windows program causes the default directory to change while a program, especially one with redirected output, is running. This phenomenon is responsible for some of the stray files found in the Windows directory, as well as other lost files. There is no cure for these ills, but they can be minimized by strict adherence to the rule that all filespecs in batch files should be complete, absolute, filespecs, even to the point of including the server designation (\\server\volume:path\file for the Novell and other network cases). There is no objection to using environment variables to store the various parts of the path. Also, it is wise to reestablish the desired drive:directory before each new stage in the batch file's operation.

Another important consideration is the need to husband the scarce resources of memory (by minimizing the use of secondary command processors) and drive letters (by use of drive:directory changes and absolute paths), though the latter conflicts somewhat with the need to map a drive letter to any directory on the same drive as the user's Windows directory that may need to be treated as the default directory, to reduce the effects of unintended directory changes from Windows.

  ** Copyright 1995, Ted Davis - all rights reserved ** 

Input and feedback from readers are welcome. NOTE: the subject of the message must contain the word "batch" for the message to get past the spam filter.

Back to the Table of Contents page

Back to my personal links page - back to my home page