The PATH to Your Command (PC Magazine Vol 3 No 6 Apr 3, 1984/Peter Norton) When we give DOS a command, such as FORMAT or CHKDSK, it has to find the program that will carry out that command. Several of the most fundamental commands, such as DIR and DATE, are built into COMMAND.COM. These are called the internal commands. If the command that we've asked DOS to perform is internal, DOS's command interpreter has the program that's needed right at hand, so it looks no further. If DOS doesn't find a command in its internal table, then it looks on disk for a command file (a file with an extension of COM, EXE or BAT) with the same name as the command we entered. Here is where DOS 2.x is different from DOS 1.x. DOS 2.x allows us to use the PATH command to look in several different places for a command file. The PATH command lets us instruct DOS to hunt for our command files in as many places on disk as we want. Without a PATH command, DOS looks for a command where it has always looked, in the current directory of the current drive. Suppose we have a PC with a drive C configured. We might keep many programs, particularly DOS programs like CHKDSK, all in one directory. Let's say the programs are kept in a directory named PROGS; the full path name to PROGS would be C:\PROGS. Ordinarily, if we are working in another directory, we wouldn't be able to get to our programs. But if we entered a PATH command, we can tell DOS to look to our PROGS directory: PATH C:\PROGS Once the PATH command is entered, DOS will keep track of it and look to the directory we've specified for command files. If we've switched our current directory somewhere else, DOS will still be able to find and execute any programs in the PROGS directory. This operation works even if we've switched the current drive. Say we wanted to work with a diskette for a moment, and we've switched out current drive to the A: drive. With the PATH command show above, DOS will still be able to find and use all the programs in our PROGS directory. To make sure that the PATH command works right, it's important to specify carefully the full pathname of the directory including its drive letter. Suppose we'd left this part off in the previous example, so that the PATH was just \PROGS. When we switched our current drive to A or any other drive, DOS would search for a PROGS directory on that drive, since the PATH command didn't specify which drive to look at. There's even more power to the PATH command. We aren't limited to telling DOS to search a single directory path -- we can give lots of paths in the PATH command. To do this, we just list all the directory paths we want DOS to search separated by semicolons, for example, two directories: PATH C:\PROGS;C:\OTHERS After we enter that command, DOS will go looking for commands in both directories in the order we gave them. In this example, DOS will search the PROGS file before it searches OTHERS. As soon as it finds the command program we've asked for, it will run it. We can put lots of paths in the search if we want to. Although I don't think that it's a good idea to scatter programs through a bunch of directories, if your programs are scattered you can still use them all conveniently by setting up a PATH command that tells DOS to look through all of them. Another use of multiple paths is that the paths we tell DOS to search can be on different drives. This turns out to be one of the best and handiest uses of the PATH command. While we might not have our programs spread out in several subdirectories, we might have them in several different drives. There are lots of good reasons for doing this. For example, if you use a RAMdisk, you could load your most frequently used programs into the RAMdisk and use the PATH command to have DOS try to find programs there first. If your RAMdrive is drive C and you usually use a disk in drive A for any programs that aren't loaded into the RAMdrive, the PATH command you'd use is: PATH C:\;A:\ With that PATH, DOS will check the RAMdrive first, and then the A: drive. Before DOS searches through any directories that we've asked it to search with the PATH command, it searches through the current directory in the current drive. This has two practical results. First, there's no need to put our current directory into the search path. DOS will look at the current directory anyway; putting it into the path will just make DOS search there twice and slow things down. Second, since the current directory is searched first, we can't use the PATH command to override any programs in the current directory. If you have a program in the current directory, but you want to use another version of it in another directory you'll have to give it another name, because DOS will use the copy of the program in the current directory before it looks elsewhere. Article continued in: Keeping Subdirectories Simple (PC Magazine Vol 3 No 7, Apr 17, 1984/Peter Norton) Subdirectories are best used by people who use hard disk systems. The extra work DOS goes through to use subdirectories on floppies makes the process painfully slow. Subdirectories are for dividing files into groups, and nothing else. Should you put subdirectories under subdirectories? Only if you like to suffer. The concept of using a complex tree structure is appealing. We logically group our files in master subdirectories and subsidiary sub-subdirectories. We build a tree structure to match the logical relationship of our files. There are two main problems with using a complex tree-structure directory. There's a performance problem: DOS has to do a lot more work to thread its way through all that foliage. There's also a human problem. It's a lot harder to keep track of directories for subdirectories under subdirectories. Although the TREE command is there to help, it's of little practical assistance. Put all your subdirectories under your disk's root directory, not under one another. Giving them distinct names is another thing. A distinct signature for subdirectory names, such as .DIR or .SUB, is recommended. If all your subdirectories have the same distinct filename extension, then you can easily call up a list of all of them with the command: DIR\*.SUB If you'd like to have them sorted alphabetically, use a pipeline command like this: DIR\*.SUB | SORT | MORE I have devised a system to easily call up the subdirectory list. I put the pipeline command shown above into a batch command file named DD.BAT. That way, by entering DD (Display Directories, as I call it), I get a sorted list of my subdirectories. At the moment I have 26 subdirectories, and this batch command helps me keep all of them straight. The real question is how to group files in subdirectories and then how to work with them. The first rule is to subdivide as little as possible. Put everything that you don't really need to separate out into one catchall directory, such as your disk's root directory. This would include all the standard DOS programs and any miscellaneous programs that you don't need to keep track of separately. My root directory, for example, has 145 files in it; almost every program I have is in there. I don't need to look at them; I just want them working for me. So I stick them all into my root directory and forget about them. Remember that the PATH command keeps the programs in your catchall directory on tap at all times. My catchall directory is the root directory of drive C. I keep the PATH command set to C:\, which provides me with immediate access to every program I have stored there, no matter what drive or subdirectory I'm using. Your catchall directory is dedicated to holding everything you never want to see. It should be filled with programs that you use but that you wouldn't need a list of. The catchall directory is a convenient place to dump things that you don't need to keep track of; subdirectories are what you use for things that you do need to keep track of. The next rule is some programs deserve their own distinct subdirectories. When they do, separate them from your catchall directory. When you expect to have more than one version of a program, for example, and you want to keep both the old and new versions, use a subdirectory. Or when a series of programs works together and you want to be able to see a list of them to remind you of their names, having a tight little subdirectory of all the programs in one working system makes it easier to use them. For example, I keep my accounting system in a subdirectory and I can quickly remind myself of all the program names with the command: DIR\GL\*.BAS (BAS, because the programs are written in BASIC.) Whenever you have programs separated out into subdirectories use the PATH command to make sure that they are on tap at all times. Suppose that your catchall is the root directory of your hard disk, drive C, and you've got two program subdirectories, NORTON and C-TOOLS. In addition, you load some programs into a RAM drive (drive D) for faster access. Here's your ideal PATH command: PATH D:\;C:\;C:\NORTON;C:\C-TOOLS There is one more situation in which it makes sense to separate out programs into their own subdirectories -- when the programs use their own data files in addition to the files that we want them to work on. Examples of programs like this are spelling checkers, which use dictionary files, and sophisticated programs like Lotus 1-2-3 that reads program overlay files and also uses initialization or profile files. Programs like these create a special situation that complicates our work. ----------------------------------------------------------------- The Stubborn Subdirectory (PC World April 1985 The Help Screen) To delete (remove) a subdirectory, the directory must not contain any files or other subdirectories, and the current directory must not be the one destined for deletion. Begin by making the subdirectory to delete the current directory [CD\directory-name]. Next do an ERASE *.* to delete all the file entries that this directory contains. Follow this by taking a directory listing [DIR] to check that this directory does not include any subdirectory entires. The only entries left in this case are the period, which indicates that this is a subdirectory, and the double period, which DOS uses to locate the directory's parent (the higher-level directory that encompasses this directory). Then change the current directory to the root directory [CD\] and execute RD\directoryname. Problem: You receive the standard error message, "Invalid path, not directory, or directory not empty." What prevents removal of this subdirectory? The steps are essentially correct. But let's review the possible errors in the DOS message: Directory not empty. Although the DOS manual notes that ERASE*.* deletes all files in the current directory (and that ERASE [drive:]path deletes all the files in the path-specified directory), ERASE does not delete hidden or system files. Hidden and system files are excluded from directory listings and from the "number of files" report in a listing's last line. Hidden and system files within a subdirectory are difficult to delete without a special utility that can list such files and change their attributes, converting them into "normal" (ERASEable) files. Not directory. In most cases, this error message refers to a misspelled directory name. It's also possible that a directory name may have been altered to include a nondisplayable character, but that is rare. Invalid path. To locate a specific subdirectory, a DOS command must be supplied with a path parameter that includes, in the correct order, every subdirectory level, from either the root directory down to the desired directory; the current directory down to the desired directory; or the current directory up to a common ancestor and then down to the desired subdirectory. If DIR-22 is the current directory and you want to remove DIR-212, you could begin the path parameter with the root dir: C>CD C:\DIR-22 C>RD\DIR-21\DIR-212 Alternatively, you could use the double period to ascend the path from the current directory to a common directory, then specify the path down from that directory: C>CD C:\DIR-2 C>RD DIR-21\DIR-212 Instead of DIR-22, suppose the current directory is DIR-2. In that case, to remove DIR-212, a descendant of the current directory, you may begin the path parameter with the appropriate child of the current directory: C>CD C:\DIR-22 C>RD..\DIR-21\DIR-212 Note that in each example the path parameter includes every subdirectory name along the specified path. Even if the root directory were the current directory (instead of DIR-22) in the first example, the path parameter zDIR-212 would be invalid because the intermediate subdirectories have been omitted. It may be that the stubborn directory is not a child of the root directory, in which case the command RD\directoryname omits the intermediate subdirectory or subdirectories. ----------------------------------------------------------------- Subdirectory Magic (PC Magazine Vol 4 No 10 May 14, 1985 User-to-User) DOS allows users to organize their files by pigeon-holing everything away in nested subdirectories. But DOS doesn't provide a convenient way to rename directories. To rename a directory, most users create a new one with the new name, copy all the files into it from the old one, and remove the old one -- or they take advantage of special utilities like those published in PC Magazine's Programming Column. Advanced users can zip into the disk directory with DEBUG and revise any filename. However, DOS 3.0 users can change any subdirectory name simply by going into BASIC 3.0 and using its NAME command. For instance, to change the name of the DOS subdirectory \SALT into \PEPPER, all a BASIC 3.0 user need type is: NAME "\SALT" AS "\PEPPER" Note that this works only in BASIC 3.x. A subdirectory name is handled very much like other filenames, except that byte 11 of its directory lising is a hex 10. Incidentally, by using DEBUG, you can hide the subdirectory listing by changing this byte from a &H10 to a &H12. ----------------------------------------------------------------- Redirecting Files and Renaming Subdirectories (PC Magazine Vol 4 No 12 June 11, 1985 PC Tutor) You can re-direct a file from one subdirectory into another without copying and erasing by using BASIC's NAME ...AS ... command in director (nonprogramming mode). Enter: NAME"\dir1\file.ext" AS"\dir2\file.ext" The RENAME command in DOS won't work because it will not accept a second path. Is there a patch (using DEBUG) to RENAME.COM that will enable DOS to do this, too? Editor's Note: This procedure does exactly as described using both DOS 2.1 and 3.0, plus adding the flexibility of changing the filename at the same time. Not only can you move files, but if you have DOS 3.0 you can even use the same procedure to rename directories, something you can't do within DOS at all. For example, if you have a first-level subdirectory named \TEXT, you can change its name to \GRAPH by entering: NAME "\TEXT" AS "\GRAPH" This is a neat trick, indeed. As for using the RENAME command in a similar manner, that simply cannot be done. Since RENAME is an intrinsic command, you would need to alter COMMAND.COM to fix the problem, and we advise strongly against trying that. ----------------------------------------------------------------- Up a Tree (PC Magazine Vol 4 No 16 Aug 6, 1985 PC Tutor) If you are in one subdirectory and want to call a program in another part of the tree the PATH option lets you to call a .EXE or .BAT program file, but not any associated data or .OVL files needed by the program. For example, a PE.EXE program needs PE.PRO and both are in the EDIT subdirectory, but PATH will only call the former. There are three possible solutions to this problem which has plagued subdirectory users ever since DOS 2.0 was introduced. First, there are a number of public domain programs that extend PATH command capability to include all file searches. Thus, as the program searches for overlay files, it will go to the correct subdirectory. Some of these programs may do strange things when you try to create a file. Second, there are more sophisticated commercial programs available that let you specify certain files that are to be found in specific subdirectories. This tends to make your environment list pretty long, but it works. The third approach is to update to DOS 3.1 which contains a program called SUBST that lets you section off a piece of your subdirectory tree as a drive. For example, if you enter: SUBST A: C: \EDIT this would make the EDIT subdirectory accessible as drive A:, and most programs search at least drive A: for required overlays. If your program can handle it, use a different drive designator (say E:) since otherwise drive A: will become temporarily inaccessible for other use. In this case, type: SUBST E: C: \EDIT ----------------------------------------------------------------- Find that Path (PC World The Help Screen August 1985) The PC AT's hard disk presents a stubborn problem. I would like to place WordStar v3.3 in a word processing directory (\WP) and develop six to eight subdirectories for text so that letters and other files on a given topic may be kept together in a specific subdirectory. Relying on a PATH command that includes the directory C:\WP, I have tried to create a series of batch files that would change to the directory containing the text I seek and then call WordStar. My efforts to access a working WordStar from any of the subdirectories have failed. After WordStar's copyright screen clears, instead of the opening menu screen, "@@@@" appears in the upper left corner of the screen. Only after copying WS*.* into each subdirectory can I edit documents. I'm encountering similar problems with other software. Only 1-2-3 works, because it allows designation of a subdirectory as well as a drive for storing worksheet files. Editor's Response: Because you have an AT, I will assume you are using DOS 3.0. DOS 3.0 contains a file called VDISK.SYS which is a device driver used to implement a RAM disk. First create a small RAM disk and copy a program's files to it. Next change the current directory of the hard disk drive to the one you want to hold your data files. Then make the RAM disk the default drive and call the program. (The commands that perform these steps can be incorporated in a batch file; in that case, you'd just call the batch file to implement the instructions.) Although many popular programs do not recognize paths, most can take advantage of a dual disk drive environment. You can keep the program's files in the current directory on one drive, usually drive A:, and your data files in the current directory of another drive. In this case we've substituted a RAM disk for drive A: and a subdirectory of the hard disk for drive B:. Many of these applications also expect all program files, such as configuration files or overlay files, to be either in the current directory of the default drive or in drive A:. Most, however, will allow you to change the drive that the application assumes is holding its program files. WordStar is one such program, which is why it would not run until its overlay files had been copied into the current subdirectory. To get WS.COM to look to the RAM disk for its overlays, use WordStar's WINSTALL program to change the system disk drive (choice R on WINSTALL's menu of WordStar features). If an applications does not let you choose a drive for its program files, use the command: ASSIGN A:=d:, substituting the RAM disk drive letter for d. After exiting the application, issue the command ASSIGN to clear the prior assignment and regain the use of drive A:. In either case, to change the subdirectories you must exit the program and, either manually or via a batch file, use the DOS command CD, then restart the program. DOS 3.1 includes a new external command, SUBST, which offers an easier and more elegant solution for just this problem. SUBST allows you to assign a path to a drive specifier in much the same way that ASSIGN redirects calls for one drive to another. A batch file such as the following allows an application to access subdirectories by referencing the substituted drive letter and, when the application is exited, to delete the substitutions: SUBST B: C:\WP SUBST D: C:\WP\LETTERS SUBST E: C:\WP\MEMO D: B:WS %1 SUBST B:/D SUBST D:/D SUBST E:/D You will still need to install WordStar so that it looks to the proper drive for its overlays (drive B: for his sample substitution), unless you substitute drive A: for C:\WP. In addition, to use drive letters beyond E:, you must reboot with a CONFIG.SYS file that includes the line LASTDRIVE=d:, where d is the last drive letter used by the system.