9–10 and 19–
“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
– 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.
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
Its full path on my Windows computer is:
I don’t want to type that full path every time
I use the command. I want to type just
I can achieve that by setting the PATH variable.
(Under MSDOS and Windows, extensions
.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.)
The PATH environment variable in my system looks like this (well, in reality it is much longer, but I simplified it here, for clarity):
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
c:\windows\system32 is where the
command line utilities reside, that come with the
operating system, in my case: MS Windows Vista.
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:
(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
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.)
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:\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
Starting with Windows Millennium, Microsoft even went
so far, that if you had the nerve to create those files
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.
Because Microsoft discourages and frustrates
setting the PATH variable in
I looked for a way to circumvent their ill-devised
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 (
I don’t know by heart what
/k means, so I looked it up again, now for
writing this article, using the command
in the command line. I found that
“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
cmd after carrying
out the command after the
/c command line
switch’. So with
/k instead of
cmd continues to run,
until it is terminated by typing
Here, the command to be carried out (executed) first is:
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.
The text file
among other things not relevant for this article, the
aforementioned setting of the PATH environment variable:
As a result, I can run my own local commands without
specifying their full path. One of these local commands
xcopybat, which is the subject of my
Copyright © 2012 by R. Harmsen, all rights reserved.