Enterprise Software

DOS is *still* not dead (part 2)

You asked for it, you got it. Here are even more reasons why knowing a little bit about DOS can make your work life easier.

By Jason Sullivan

In my first article, "DOS is *not* dead," we began our journey into the depths of the DOS batch language, covering the basics of DOS batch files in general and the XCOPY32 and DISKCOPY commands. In this edition of “DOS is *not* dead,” we will present some more useful DOS commands, specifically ECHO, PATH, and > (redirect), once again with an eye towards how they can be used to make the life of a person in a tech support position a little easier.

Test for echo …
The echo command is one that is often overlooked, but I will now show you how useful this underrated command can truly be. Let’s start with the basics. Inserting the line @echo off|on in a batch file will either disable or enable the display of the batch file’s commands to the monitor. It’s generally considered good form to insert @echo off at the beginning of a batch file to eliminate screen after screen of scrolling text for the end user.

Now let’s look at what is probably the second most common usage of the echo command—appending to or replacing text in a file. In order to make this relevant to making the life of a tech easier, I’m going to use a real-world example I recently faced.

Case study: Updating a database
The company I work for has an old DOS-mode program that uses a command-line terminal emulator to connect to a UNIX machine, download compressed files containing updates, decompress them (using the venerable PKZIP program), and apply the updates to a database. It’s a bit archaic, but it is what works for them now, and a new version is in the works.

Now, the problem arose where a remote machine got this software installed, but the tech did not install PKZIP before he left. Normally, this would not be a major issue—we would just remotely control the machine, copy the directory containing the software over (ah, the good old days when a program could be moved to a different machine simply by moving one directory … ), edit the PATH statement in the AUTOEXEC.BAT file (in a minute we’ll have a quick discussion of the PATH statement), and we would be done.

In this case, however, the problem existed on more than a few machines, so an automated solution would:
  • Eliminate the potential for human error.
  • Allow the users affected by this issue to fix the problem at their convenience, rather than having to deal with the problem of coordinating schedules.
  • Be handy to have around if the problem appeared again in the future.

So, after weighing these factors against the knowledge that the batch file to correct the problem would be something that would only take a few minutes to create, the decision was obvious. After I explain the two additional commands I used to make this solution work, I’ll reveal the batch file I created to solve this problem.

Don’t lose your PATH
The PATH statement, so rarely seen in these days of 32-bit operating systems, is crucial to the operation of batch files and some older, 16-bit programs. It is essentially a list of directories that contain certain critical files (such as C:\Windows\Command, which contains many of the DOS commands) so that a program knows where to find them.

Correctly loading the PATH command is what allows a user (or, more likely, a batch file) to execute a program contained in one directory from an entirely different directory without having to type out the whole file path. As a clarifying example, let’s assume that you have a boot floppy with all of your DOS programs in your A:\DOS directory, and you need to run an XCOPY32 of the A:\TEST\FIX directory to the C:\BROKEN\PROGRAM directory.

There are two ways to handle this challenge. First, you could type the command:

In addition, if you had added the line PATH=A:\DOS to your AUTOEXEC.BAT file, you could use the command:

You may be thinking that this distinction seems trivial, but when you end up typing the command a couple dozen times, you’ll be glad for the reduced keystrokes. Also, many older programs were written with a dependence on the PATH parameter being properly configured. This way, no matter where the end user installed the external programs it relied on to execute properly, it would be able to access them.

The proper syntax for adding to an existing path is PATH=%PATH%;<what you are adding>. By adding the %PATH% at the start, you will preserve any path statement that has previously been set. The semicolon (;) is used by the PATH command to separate individual directories. It should be noted that, although WIN9x doesn’t usually put a PATH statement in the AUTOEXEC.BAT file, it still sets a PATH list during boot up. This behavior is important to keep in mind when changing PATH statements in Windows.

You can prove this to yourself by opening an MS-DOS command prompt window, typing PATH, and then pressing [Enter]. At the very least, you should see PATH=C:\WINDOWS;C:\WINDOWS\COMMAND, though there may be more entries in the list if you have installed a program that modifies the path.

Redirecting the flow
In DOS, the greater-than symbol (>) is used for redirecting the output of a command to a text-formatted file. When a single > is used, the output file will be replaced by the results of the command. When you use two greater-than signs (>>), the results will be appended to the end of the file. Here are some sample commands:

The DIR command displays a list of files in a particular directory, in this case the C:\ directory. The first command would either:
  • If none existed, create a file named DIRLIST.TXT in the C:\WINDOWS directory that contained a listing of all the files and directories contained in the C:\ directory, or
  • Replace any preexisting DIRLIST.TXT file.

The second command would either:
  • Create the same DIRLIST.TXT file if none was there, or
  • Move to the end of an existing DIRLIST.TXT file and write the data there, thereby preserving the information that previously existed in the file.

How it all comes together
So, now that we have all the necessary pieces in place, here is the batch file as I wrote it:

We placed this batch file (named FixIt.bat) on a network drive. In the folder containing the batch file, we created a subfolder named PKZIP that contained the PKZIP program files. The period at the start of the ‘.\PKZIP\*.*’ path in the XCOPY32 command is special.

By using this syntax—rather than a full path—this batch file will work even if the user has changed the drive letter to which that network location is mapped. Windows interprets a period used in this manner as “starting from the folder this command is being executed from.”

This way, the batch file will work, whether it is sitting on the network, copied to a floppy, or burned to a CD-ROM, as long as you adhere to the basic premise that “the batch file is in a directory that contains a subdirectory, named PKZIP, which contains the program files that need to be copied to the end user’s machine.”
To comment on this tip or to share your own favorite DOS technique, please post a comment below or follow this link to write to Jason.

Jason Sullivan is a technical support specialist for the Ag-Field division of the Monsanto Corporation. He currently is one test away from his MCSE and two away from his MCDBA—a situation he is working diligently to correct. He considers himself a true geek—a designation marred only by the fact that he is married and has two children. He likes to think that having an Internet-loving spouse and personalized license plates that read ‘IT GEEK 1’ help offset this fact, though.

Editor's Picks

Free Newsletters, In your Inbox