PATH and the DOS box

9–10 and 19–20 December 2012

DOS box??

“DOS box?? Are you still using the DOS box? Are you a dinosaur?”

Well, yes I am. And a fossil too. But I like it.

On a Windows system (Windows 95 and newer, anything after Windows 3.11), what people call the DOS box, is in fact a 32 bits command line, capable of running 16 bit and 32 bit programs.

This Windows command line – called cmd – is still not half as powerful as a Unix shell (sh, bash, ksh, csh, tcsh etc.). But under Windows Vista, for example, it does support long names, and the asterisk wildcard (*) can also appear at the start and somewhere in the middle of a name, not just at the end, as was the case in earlier versions.

Program invocation

In a command line, you start a program by typing its name, followed by pressing ‘enter’ (sometimes called ‘return’, or indicated with the symbol ⏎).

Instead of just the name, you may need to type the full path to where the program (command, script, batch file, or whatever it’s called) resides on the disk. But that’s inconvenient. For example, xcopybat is the command (a self-made batch file) that I’ll be discussing in the next article. Its full path on my Windows computer is: c:\ruud\bin\xcopybat.bat .

I don’t want to type that full path every time I use the command. I want to type just xcopybat⏎. I can achieve that by setting the PATH variable.

(Under MSDOS and Windows, extensions like .bat and .exe have a special status and may be omitted. On Unix systems, programs don’t normally have such file name extensions. But if a program has a file name extension anyway, on Unix you need to include it, when you invoke the program from the command line by name.)

PATH

The PATH environment variable in my system looks like this (well, in reality it is much longer, but I simplified it here, for clarity):

PATH=.;c:\bin;c:\ruud\bin;c:\windows\system32;

As you can see, the PATH variable specifies some paths, separated by semicolons (;). This is different from the situation on Unix systems, where the colon (:) is used for this purpose. Programs or script files in the specified paths (folders, directories) can be invoked from the command line, just by their names, without their full path.

The command line processor will search the specified paths in the PATH variable in the specified order, in order to look up the command (script, program), the name of which was typed in the command line, with the intention of running it.

In my example, the PATH variable contains:

The current directory, encoded by the dot, ‘.’. If I remember correctly, under DOS and Windows the current directory is included in the PATH implicitly, so you don’t have to mention it. Under Unix however, you must mention it explicitly. I am experienced in both types of system, so I made it my habit to always include it, to be on the safe side.
c:\bin is where I keep some Unix command line utilities, implemented for DOS, which may come in handy.
c:\ruud\bin is my own private bin directory, where I keep scripts and programs of my own making. One of them is the aforementioned xcopybat.
c:\windows\system32 is where the command line utilities reside, that come with the operating system, in my case: MS Windows Vista.

The bin part in some of the path names implies that the directories are intended for binaries, that is, executable programs.

In this context, ‘binaries’ includes scripts, i.e., non-binary text files that combine several other program calls and commands. On DOS and Windows, these are called batch files. Hence their file name extension: .bat .

(Of course English words combinations like ‘trash bin’, ‘dust bin’ and ‘garbage bin’ exist. So maybe this Unix concept of ‘bin’ is also a pun, suggesting a good-humoured advice to programmers like ‘you might as well put that silly program you wrote in the garbage can, to see what it does.’ Unix stuff is full of such jokes.
On the other hand, these expressions seem to be chiefly British, and early Unix was more like an American development.)

Autoexec.bat

Just like I don’t want to type the full path to every command, I also do not want to specify the PATH variable every time I start a DOS Box. So it should be set once and for all. Traditionally, that was done in a file called c:\autoexec.bat .

This and c:\config.sys were the start-up files for an MSDOS system. That was many years ago, when MSDOS was the operating system, and Windows (versions 3.10 and 3.11) was just a graphical shell, running as a program on DOS.

However, in its infinite wisdom, for the benefit of us unwitting users, Microsoft decided to abandon the files c:\autoexec.bat and c:\config.sys .

Starting with Windows Millennium, Microsoft even went so far, that if you had the nerve to create those files c:\autoexec.bat and c:\config.sys anyway, it would rename them on start-up, so their contents became ineffective.

Apparently, Microsoft wanted everyone to move away from the command line and do everything in the graphical Windows environment. I can’t agree with that. Even though I too use Windows a lot, the way it is intended to be used, for some, even for many tasks, a command line is just so much handier, more flexible, straightforward and powerful. Often clearer too: you see what you are doing and what happens.

Perhaps this is a matter of taste, and of what you have grown accustomed to. As I said, I am a dinosaur. I have been working with computers since 1975, and with the Unix command line since 1985. My first experience with DOS was in 1990 – and it was a big disappointment! No sooner than 1994 or so I gradually began to use the graphical user interface of Windows as well.

Icon property

Because Microsoft discourages and frustrates setting the PATH variable in autoexec.bat, I looked for a way to circumvent their ill-devised blockade. And I found it: the command line start-up file can be specified in the properties of the starting icon. Here’s how:

You look at what you start the DOS box with. This can be an icon on the desktop, or an icon in a subfolder on the desktop. The DOS box is also accessible from the system’s start menu. This is usually found under All Programs, Accessories, Command Prompt.

On all these starting icons, you click with the right mouse button. At the bottom of the menu which unfolds, you choose Properties and then (if necessary) you click the tab Shortcut. There you see a field labelled Target. On my system, that field contains this:

%SystemRoot%\system32\cmd.exe /k c:\ruud\bin\auto.bat

This means the icon starts the Windows command line, by full path (in part invoked through the variable SystemRoot), and name (cmd). I don’t know by heart what /k means, so I looked it up again, now for writing this article, using the command
cmd /?
in the command line. I found that /k means:
“Carries out the command specified by string but remains”.

This may sound cryptic, but this word “remains” is to be interpreted as meaning the opposite of ‘terminating cmd after carrying out the command after the /c command line switch’. So with /k instead of /c, cmd continues to run, until it is terminated by typing exit⏎ .

Here, the command to be carried out (executed) first is:
c:\ruud\bin\auto.bat .

That is a text file, created with a text editor such as Notepad. If you insist, you can also make such a text file using a word processor like MS Word. But then you must take care you save the file as a text file, not as a Word document.

PATH automatically set

The text file c:\ruud\bin\auto.bat contains, among other things not relevant for this article, the aforementioned setting of the PATH environment variable:

PATH=.;c:\bin;c:\ruud\bin;c:\windows\system32;

As a result, I can run my own local commands without specifying their full path. One of these local commands is xcopybat, which is the subject of my next article.