Previous | Index | Next

Master 512 Forum by Robin Burton
Beebug Vol. 8 No. 3 July 1989

Using the DOS+ PATH command

We've covered a lot of varied territory in the twelve months since the first Forum, so I thought it was about time that we got back to basics for a change.


Those who have read the Forum since its inception in July last year will remember that our initial topics were batch files and the memory disc. Since then there hasn't been much about standard DOS+ facilities so we'll put that right now.

We'll start with discs. You're probably quite familiar with most of the facilities, but even so you may not use them all to their full advantage. The trouble with some of them is that they tend to be used when you set up a new application and are then forgotten.

I was reminded by an accident this morning, while I was preparing to write the Forum, so I'll tell you the story. My micro, disc drives etc. are in a PC style case with a separate keyboard and one of the extras is a cooling fan. Last week I had to partly dismantle the micro to change some ROMs, needed for a talk I was to give. As micro cooling fans are remarkably good at collecting and compacting airborne dust, at the same time I cleaned the fan. Obviously I missed a bit. Today that bit moved and landed on my DOS+ word processor disc, ruining it by scratching a visible groove round 60% of track zero.

I heard it immediately (an unpleasant repeated scratching) but it was too late for the disc. Fortunately the drive heads were OK but I was particularly sad because that disc was the first that I ever bought for my first drive in 1983. What do you mean? Of course I had a backup even if it wasn't quite the latest version!

A few 'fine tuning' tweaks were missing from some batch files, and three or four user-defined key functions from the word processor definitions file. It only took half an hour to bring it up to date, but along the way I was reminded of some of the things we tend to forget (e.g. "I'll back it up afterwards". I remembered today!).


Of course you know what a path is in disc filing systems, but do you exploit the DOS+ 'PATH' command to full advantage?

There's no excuse for neglecting 'PATH'; it's a permanent command, which means it's always immediately available. This is because it's built into the memory resident portion of DOS+, as opposed to transient commands like 'COLOUR' which must be loaded from disc each time. Initially 'PATH' isn't set. In effect it defaults to the root directory of the current drive, unless you change it.

It's usual to include the setting of 'PATH' in your 'AUTOEXEC.BAT' file, especially if you use a hard disc, but it can be altered at any time when you are in DOS command mode, either by another batch file or by a manually entered command.

The simplest form of the command is to enter 'PATH' with no parameters and it will then display the current setting. Hands up those who tried it and saw nothing but the normal prompt?

It's a usual and convenient practice to keep the most frequently used DOS utilities in their own directory on each application disc. Most people call these directories 'DOS' (which perhaps surprisingly is not a prohibited name) though 'DOSTOOLS', 'UTILS' or 'DOSUTILS' are also popular.

This technique is useful because it means your 'working' directory display won't be unnecessarily cluttered by the DOS commands. Of course it's also usual to have the disc containing this in drive A: (or C: for hard disc).

On the other hand if you're working in a directory called 'DOCFILES' in drive B: and wanted to change the attributes of a file called 'FORUM.DOC' to read only, if you issue it the hard way the command is:


which is not exactly short and convenient. This is especially important since the full pathname of the utility must be entered every time you use it if it's done this way.

It won't surprise you to hear that there's a short cut, and that it's 'PATH'. Using our example names if we had issued the command:


while we were in the root directory, DOS would always search the 'DOSUTILS' directory for any command which it couldn't find in the current directory. It becomes irrelevant where our wanderings take us on the disc and how many directory levels down we may have gone. There's just one point to note here, and that is that in this example there's no drive identifier. This means that DOS will always expect to find 'DOSUTILS' on the current drive, whichever it happens to be at the time.

It can, in some circumstances, be useful to issue the 'PATH' command without a drive identifier, but more often than not you'll want to specify a particular drive too. This requires only the addition of the drive ID in the usual fashion, so for drive A: the above command becomes:


When the command is issued like this, with a drive specified, it no longer matters what the current drive happens to be. The correct directory will always be searched for on the original drive.

Naturally, this means that you shouldn't change the disc referred to by 'PATH' unless 'PATH' is reset or the new disc also has a similar directory of the same name at the same level, in which case that will be used.

So far it's much like 'LIB' in ADFS, but actually it's more flexible and tolerant. For a start, as mentioned, even if you do change discs, so long as the new one contains the right directory at the right level there's no problem. Fortunately DOS+ doesn't have the annoying 'Disc changed' error. By sticking to a common naming convention on all your discs that's one problem you can completely eliminate.

Secondly, PATH will be used to search for any command that DOS doesn't recognise, so any 'CMD', 'COM', 'EXE' and 'BAT' files can all be accessed by this means from anywhere in the system.


Setting a path is obviously useful, but what happens if your 'UTILS' directory is on one drive and you also want a path on another, or you would like to keep your batch files in a directory of their own, separate from the DOS utilities? This is no problem. DOS permits multiple simultaneous paths to be declared, and they're just as easy to set up.

For illustration, suppose that we decided to keep each of the four executive file types in separate directories, all accessible from any other directory without explicit references. Using the directory names 'CMD', 'COM', 'EXE' and 'BAT' for each file type, the command would be:


Notice that the only addition needed is that each of the paths we define is separated from the next by a semi-colon.

As it stands the above definition assumes that all these directories are on the current drive and that they are all just one level down from the root. In fact each path can be of a different length and/or can be on different drives – just supply the information as appropriate, remembering to separate all directory names in each path by a back-slash, like this:



There is one restriction to be remembered, but in practice it's unlikely (or at least it ought to be) that you'll be troubled by it.

This is simply the total length of the command. In DOS, the maximum allowed for any single command line entry is 127 characters. This 'restriction' is because, on loading, 'COM' files have a header of &100 (256) bytes added at the front by DOS, and half of this (minus a byte) must be capable of holding the complete original command line as passed to the program from 'COMMAND.COM'.

This is done so that no matter what happens to the rest of the memory during execution, a program can always refer back to an unchanged (by anything else) copy of its original command parameters.

As a result of this restriction, if each of the pathnames you were to specify consisted of several full length directory names, you wouldn't be able to enter so many separate paths. Remember that the command itself takes five characters including the following space, and each full length directory name can take nine with its back-slash, plus another two for a drive ID for each path if this is needed too.

As I said, this shouldn't be a problem. If you commonly use more than two or three directory names in any one path I'd suggest the contents of your discs urgently need sorting out, restructuring and simplifying.

There are three more points to remember when you use the PATH command. First, whenever you issue the command all previous paths are cancelled, so you can't just add an extra path. You must re-enter all previous paths, plus any new one(s), as a single command.

Second, no validation is carried out when you define your paths so care is needed when the command is used manually. A mis-typed directory name will NOT cause an error at the time the path is set, even if there's no such directory anywhere in the system. If you then issue a command which should be found in the (correct) path directory, but isn't, the error you'll get is the usual 'Bad command or filename'. There is no 'Can't find Path directory' or 'Bad Path' error. For example, try:


and you can immediately confirm that it has been accepted. Follow this with an invalid command (e.g. HELLO). These errors can be very difficult to spot when a batch file fails some time later, or an unexpected 'Cannot load COMMAND.COM' pops up.

The last item concerns the way DOS works in looking for commands. The first directory examined is always the current one, the last is the root. In between, if multiple paths are set, each of them is searched in the order you specified them, so ensure that the most frequently used paths are defined first.

It's easy to practice with the path command if you're not completely sure yet. In this example we'll assume drive A: as the current drive, but the principle is the same no matter which drive you're using. You'll need a writable disc in drive B: because we'll be creating a new directory and putting a file in it. When you're ready enter the following, pressing Return after each line:

ECHO Hello sailor!

The commands select drive B: and create a directory called 'BATCHDIR'. In this we create a file called 'HELLO.BAT' containing a message. Control-Z ends the file copy and drive A: is reselected. Finally the path is set and you'll see that the command 'HELLO', issued from drive A: causes our message to be displayed from the file in drive B:.

Repeat the exercise with another disc and then try swapping the two discs in drive B:. You'll see that DOS doesn't care which disc is used as long as the path names are the same. You can also then set the path with no drive ID. Put one disc in each drive and change drives to prove that PATH's drive can remain variable, even though the directory is fixed. Don't forget to tidy up afterwards. Delete the batch files first. You might also need to reset the path before you can remove the directories.

Next Forum we'll look at a few more under-used facilities, including floating drives.

Previous | Index | Next

About the Master 512 | Bibliography