Better Batch Files Through Command Extensions

The first batch files arrived alongside the very first versions of MS-DOS and PC-DOS. If you have been around the personal computer for many years, you undoubtedly remember, perhaps not fondly, AUTOEXE.BAT. Power users probably had two or more of them, and some means by which to choose which one to use the next time they engaged their DOS boot diskette. Later came such features as batch files that displayed menus, read inputs from the beloved DOS prompt, and made processing decisions based on those inputs. More sophisticated batch jobs accepted command line arguments, just as did the commands that were built into DOS itself, and the dozens of utility programs, such as XCOPY, that came with it.

The Primitive Command Line Interface

While those early batch files accepted arguments, sometimes called parameters, the command parser was very picky. Testing the value of an argument was extremely limited, and followed a syntax that was familiar to C programmers, but alien to most other computer users, as shown in Listing 1.

IF "%1" == "DE4DATA" GOTO CHECK_1
IF "%1" == "de4data" GOTO CHECK_1
IF "%1" == "De4data" GOTO CHECK_1
IF "%1" == "De4Data" GOTO CHECK_1

 

Listing 1 shows the only way you could have any degree of case insensitivity in your command line argument tests in MS-DOS and PC-DOS.

Listing 2, below, shows a set of tests that gives more complete coverage.

IF "%1" == "DE4DATA" GOTO CHECK_1
IF "%1" == "de4data" GOTO CHECK_1
IF "%1" == "DE4data" GOTO CHECK_1
IF "%1" == "DE4Data" GOTO CHECK_1
IF "%1" == "DE4DAta" GOTO CHECK_1
IF "%1" == "DE4DATa" GOTO CHECK_1

 

IF "%1" == "dE4DATA" GOTO CHECK_1
IF "%1" == "de4DATA" GOTO CHECK_1
IF "%1" == "de4dATA" GOTO CHECK_1
IF "%1" == "de4daTA" GOTO CHECK_1
IF "%1" == "de4datA" GOTO CHECK_1

 

IF "%1" == "De4Data" GOTO CHECK_1

IF "%1" == "De4DaTa" GOTO CHECK_1
IF "%1" == "De4DatA" GOTO CHECK_1

 

IF "%1" == "DE4data" GOTO CHECK_1

IF "%1" == "DE4Data" GOTO CHECK_1

Listing 2 requires 16 tests to provide partial case sensitivity.

That is 16 lines of code to provide partial case sensitivity for one command line argument! Although the example above is extreme, it illustrates why batch programmers usually confined themselves to terse parameter values.

The Command Parser Grows Up

Windows NT brought with it a new command processor, CMD.EXE. Unlike its ancestor, COMMAND.COM, CMD.EXE is a full fledged 32 bit console mode Windows program. It can do everything that COMMAND.COM can do, and much more. One of its most useful new capabilities arises from command extensions, which are enabled by default. You can turn them off, but why?

IF "%~1" EQU ""                         GOTO DO_ALL

IF /I "%~1" EQU "DE4Data"               GOTO CHECK_1
IF /I "%~1" EQU "Home_Office"           GOTO CHECK_2
IF /I "%~1" EQU "Remote_IncrEase"       GOTO CHECK_3
IF /I "%~1" EQU "Home_Office_IncrEase"  GOTO CHECK_4
IF /I "%~1" EQU "UTIL"                  GOTO CHECK_5
IF /I "%~1" EQU "QB4_Source"            GOTO CHECK_6

Listing 3 does, in its second of only 7 lines, much more than the 16 lines shown in Listing 2, because it is fully case insensitive.

Listing 3, taken from a production batch file, illustrates several of the capabilities provided by command extensions.

1. The second through seventh lines modify the IF command with a new /I switch, making its tests fully case insensitive.
2. All seven lines take advantage of another command extension, the tilde (~), to strip away quotation marks around the command line argument ("%~1"). I'll say more about this shortly.
3. The third command extension illustrated in Listing 3 is the mnemonic relational operator, EQU. Thanks to command extensions, the IF command now supports a complete set of relational operators.

Who Can Use Command Extensions?

By default, command extensions are enabled, and are available in all versions of Windows that derive from the Windows NT code base, starting with Windows NT 4. In addition to NT 4, this includes Windows 2000, Windows XP, Windows Server 2003 and 2008, Windows Vista, and Windows 7.

Why Keep the Quotation Marks?

Despite many improvements, the command parser still has a few quirks, one of which is that it sometimes gets confused by bare words that are neither internal commands, nor recognizable program or batch file names. Thus, it is usually best to keep the quotation marks around the text against which an argument is being compared. However, if the argument is enclosed in quotation marks because it contains embedded spaces, and the test, itself, is also enclosed in quotation marks, the result is that the comparison string is enclosed in two sets of quotation marks, as shown in Table 1.

Command Line Argument	“Document to Process.doc”
Old Style Comparison	If “%1” == “This is the Document.doc”
Outcome of Old Style Comparison	If ““This is the Document.doc”” == “This is the Document.doc”
New Style Comparison	If “%~1” == “This is the Document.doc”
Outcome of New Style Comparison	If “This is the Document.doc” == “This is the Document.doc”

Table 1 illustrates the behavior of old style comparisons, done without the benefit of command extensions, and the new style, which leverages them to make the test work as you would expect.

Conclusion

While graphical interfaces and tools are nice, and they have a valuable place in our tool sets, so does the lowly command line interface. Batch files are fairly easy to write, test, and debug, run fast, are ready to run without a compiler or specialized interpreter, run without fuss on any machine, and can go where a program with a graphical is a waste, such as in logon and logoff scripts and scheduled tasks, none of which has a visible user interface.

While I do my share of graphical programming, batch files remain an essential part of my production environment, and occasionally become part of packages that I deliver to clients.

Use the following resources to learn more about command extensions, and start building flexible, powerful, modern batch files.

References

1. http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/if.mspx?mfr=true is the official documentation of the modern IF command.
2. http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/cmd.mspx?mfr=true is nominally about the new command processor, CMD.EXE, but it includes basic information about command extensions, including several ways to enable and disable them.
3. http://www.robvanderwoude.com/local.php is a discussion of the SETLOCAL and ENDLOCAL commands, which includes one of several nifty tests that you can use to verify that command extensions are enabled.
4. http://technet.microsoft.com/en-us/library/bb490920.aspx lists and documents the full set of relational operators that become available with command extensions enabled.

Formatting Windoes Explorer Detail Columns to Fit Contents

If you use Microsoft Excel, you may have discovered a shortcut that is undocumented, so far as I know, that allows you to auto-fit a single worksheet column to fit its contents by double-clicking on the divider between the column and its right hand neighbor.

Today, I discovered that, not too surprisingly, the same shortcut works in the Windows Explorer. Since I work in the Detail view most of the time, I am always adjusting the widths of one or another of its columns, depending on the information that is currently of most interest. Just for fun, I decided to test the double-click. Sure enough, the width adjusted, exactly as it would in Microsoft Excel!

In both cases, you must double-click on the border at the top of the window. In Excel, this is the part where you see the column labels, A, B. C ... etc.

Likewise, in the Windows Explorer, you must double-click on the area that contains its column labels, File, Size, Type, Date Modified, ... etc.

This new knowledge will save me lots of time!

To Copy A Directory Tree, Without Copying the Files

For the first time in a long while, I just needed to duplicate the structure of a directory tree, without copying the files.

The Problem

Duplicate the structure of the directories that hold my program source code, so that I can move the archives of completed projects out of the active development directories, which are backed up nightly to an offsite location, while keeping them organized as they currently are in the development directories.

The Solution

I began by starting a conventional copy, using the Windows Explorer. As it got underway, it occurred to me that there had to be a more efficient way. A quick Google search yielded instant results.

The search term was straightforward, "copy directory structure only."

The command that got the job done, in less than a minute, is equally straightforward, as shown in Listing 1, which I copied and pasted from my command prompt window.

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

 

C:\Common_Data\WinZip_archives\code_libs>XCOPY "C:\Documents and Settings\David\
My Documents\Programming" /T /E

 

C:\Common_Data\WinZip_archives\code_libs>

 

Listing 1 - The command above, XCOPY "C:\Documents and Settings\David\My Documents\Programming" /T /E, leverages the sparsely documented T switch of the faithful XCOPY command, which has been a stalwart friend since at least 1989.

More Shortcuts

OK, so I cheated.

• I used a shell extension to open my command prompt window with the target directory already made current.
• I used the Windows Clipboard to get the name of the source directory right the first time.

This second shortcut is especially noteworthy, because it calls attention to another sparsely documented feature of Windows, which is that pretty much anything that you can highlight can be copied, using the CTRL-C keyboard shortcut.

Among other things, this means that you can copy from any of the following locations.

• The address bar of a Windows Explorer window.
• The file name text box of a file property sheet.
• Any other text box.
• Some other text on property sheets. Among others, I've had success with the following.
• File create, modify, and access dates on file property sheets.
• File sizes, also on file property sheets.
• Version strings, from the Version page of the property sheet for an EXE or DLL file.

If you need text from almost anywhere in a Microsoft Windows application, try to highlight it. If it's text on the flat surface of a dialog box, try dragging the mouse across it. If you can highlight it, a quick CTRL-C  puts it into the clipboard.

For Geeks Only - Why This Works

Although it isn't obvious, selectable text lives in a Text Box control. It isn't obvious that it's a control, because of the way its properties were set at design time.

• Border is set to None.
• Background is set to Transparent, or its color is set to be the same as that of the dialog box surface.
• 3D effects are off.

How these settings are applied depends on the development environment, but all can be set in any environment that lets you build custom dialog boxes and other types of forms. Among others, this includes VBA (hosted in Microsoft Access, Word, Excel, PowerPoint, and Outlook, among others), Visual Basic (classic versions 1 through 6), VB.NET, and C#. This also includes the WinBatch dialog editor, and probably numerous others.