The Windows Command Prompt


The Windows Command Prompt

The Windows GUI is fine for the casual user , but for tasks that you have to perform over and over every day, the Command Prompt window is your best friend. Visualize the difference between a hunt-and-peck typist and a Mavis Beacon Teaches Typing summa cum laude graduate. That's the difference between someone who uses only the GUI, and someone who knows how and when to take advantage of Windows' command line interface. Once you've committed the necessary commands to memory, you can type them much more quickly than you can take your hands off the keyboard, grab the mouse, and navigate through endless menus .

If you don't believe me, do an experiment: See how long it takes to get to the Windows Firewall control panel using the GUI, versus typing control firewall.cpl followed by the Enter key. The command line is also less distracting: You can just type the command you want without having to read and scroll through all of the commands you don't want to use.

Speed-typing aside, there are several other important reasons to know how to use the command line, batch files, and Windows Script Host:

  • There are some commands and management tools available through the command line that aren't available through the GUI.

  • You can put often-used sequences of commands into a batch file or script, and repeat complex tasks (or even simple tasks) with just a few keystrokes.

  • Batch files and scripts serve as a form of documentation. Not only do they perform a job, they are themselves a description of a procedure, step by step, with nothing left out.

  • Batch files and scripts encapsulate skill and knowledge. If you write one to perform a complex task, it will be much easier to teach someone else how to use the batch file than it would be to show him how to perform all of the individual steps inside.

The Windows Command Prompt window looks and behaves a lot like the screen you may remember from the pre-Windows days of MS-DOS. But, the Command Prompt window is a gateway to a full 32-bit environment closer to UNIX than MS-DOS. Command prompt programs (technically, they're called console applications ) are actually full-fledged Windows programs; the only difference is that their window displays text output with no graphics, and it accepts typed text input; it's like using a very powerful electric typewriter.

Note

The next few sections describe how the Command Prompt environment works in some detail. If you want to skip ahead to the "how to" information, jump over to "Editing Command Lines" on page 382.


What the Command Prompt Really Does

When you use the Start menu to open a Command Prompt window, what's actually happening is that you're running a program named cmd.exe , the Windows command shell. Cmd is defined as a console application, as opposed to a GUI application, so as the program is started up, Windows opens a blank, black window. Cmd prints a prompt, a bit of text to indicate that it's waiting for you to type something; it might look like this:

 C:\Documents and Settings\brian> 

When you respond by typing a command and pressing Enter, cmd looks at the first word in the line of text you typed. It interprets this as the name of the program you want to run. It searches for an executable program file with this name , and if it finds one, starts up the program. Any other text on the line you typed is provided to the program for it to interpret, according to its own conventions, telling it what you want it to do.

For example, if I type the command

 ping www.mycompany.com 

cmd will search several standard folders for a program named "ping". It will find ping.exe , which is a network testing utility, in \windows\system32 . Cmd will instruct Windows to run ping.exe and provide it with the additional text I typed, www.mycompany.com . Ping interprets this additional text as the name of another computer whose network connection I'd like to test. It will perform the network test and print a few lines into the Command Prompt window. When the ping program exits (finishes), cmd.exe prints another prompt, and the cycle starts over.

Environment Variables

Where exactly does cmd look for these program files? The list of locations is defined by a setting called the PATH environment variable . The Environment is a set of text values that Windows makes available to all programs. Each one consists of a name like PATH or USERNAME , followed by an equals sign and additional text. You can see them by opening a command prompt window and typing set followed by the Enter key. The output will look something like this:

 ALLUSERSPROFILE=C:\Documents and Settings\All Users.WINDOWS APPDATA=C:\Documents and Settings\brian\Application Data CLIENTNAME=Console CommonProgramFiles=C:\Program Files\Common Files COMPUTERNAME=JAVA ComSpec=C:\WINDOWS\system32\cmd.exe HOMEDRIVE=C: HOMEPATH=\Documents and Settings\brian . . . 

Each of these lines shows the name of an environment variable and its value. Windows defines most of these variables and values for you, though you can define environment variables for your own use in batch file programming. Of the predefined variables, Windows uses PATH and PATHEXT to locate programs that you want to run.

Note

Actually, Windows uses the PATH to locate any program it's told to run, whether it's from the command line, a line in a batch file, the Start menu's Run dialog, a shortcut, or from inside another program. It also uses the PATH to locate the Dynamic Link Libraries (DLLs) used by most Windows programs. When a program needs to use a DLL, Windows first looks in the folder that contains the calling program's .EXE file, and then it searches through the folders in the PATH .

Of course, if a command or DLL file is specified using a full pathname, the PATH list isn't used.


When you type a command on the command line, cmd first checks to see whether the command is one of the built-in commands that it handles directly, by itself, without any program file at all. Built-in commands include dir and several others, which are discussed later in this chapter.

If the command isn't recognized as a built-in command, cmd looks at the PATH environment variable and interprets it as a list of folders to search for a program file. The folder names are separated by semicolons, so for the PATH in the environment variable list you saw earlier, cmd will look at the following folders, in this order:

 C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\system32\WBEM c:\bin c:\bat 

The first three folders were put into the PATH list by Windows so that cmd can find the standard programs provided with Windows: notepad, ping, and so on. I added the second two folders myself , so that cmd can find some additional programs and batch files that I wrote; I'll tell you how to do this later in this chapter.

As it scans through these folders, Windows looks for a file whose name matches the name you typed on the command line, and whose extension (file type) is any one of those listed in the PATHEXT environment variable. Table 9.1 lists the most common file extensions used on executable files, batch files and scripts.

Table 9.1. Common Program File Extensions

Extension

Type of Program

.COM

MS-DOS executable file, absolute binary format

.EXE

Standard MS-DOS, Windows, OS/2, or other application

.BAT

Batch file, written for cmd.exe or MS-DOS command.com

.CMD

Batch file, written for cmd.exe

.VBS

Windows Script Host script, written in VBScript

.VBE

Encrypted VBScript script

.JS

Windows Script Host script, written in JScript

.JSE

Encrypted JScript script

.WSF

Windows Script Host script, in XML format

.WSH

Windows Script Host settings file


To continue with our sample command,

 ping www.mycompany.com 

Because ping isn't one of the built-in commands, cmd looks in the first folder listed in the PATH environment variable for a file named ping.com . If a file with this name is present, cmd instructs Windows to run the program. If ping.com isn't found, cmd checks for ping.exe , then ping.bat , and so on, through the PATHEXT list. If no file is found in the first PATH folder, cmd goes to the second folder and repeats the process. If a file can't be found in any of the folders, cmd prints an error message and gives up.

Of course, if you type a specific file extension as part of your command line, for example, if you type

 ping.exe www.mycompany.com 

Windows will look through the PATH folders only for a file with the specified extension, and will not use the PATHEXT list. Likewise, if you specify the command using a specific path, as in

 c:\windows\system32\ping www.mycompany.com 

Windows will not search through the PATH list.

Tip

If the same program or batch file is in more than one folder in your search path, and the first one that cmd finds is not the one you want, type the full pathname before the command to eliminate any ambiguity about which copy of the program you want to use. For example

 c:\windows\system32\ping 

tells cmd exactly where to find the ping program.


In any case, when Windows has located a program file that matches the command name you typed, it uses the file's extension to see what type of program it is to run. The extension .COM indicates a very old-style MS-DOS application. .BAT and .CMD files contain commands that cmd.exe is to interpret one line at a time just as if you were typing them at the command prompt. .EXE files are executable program files that could be MS-DOS programs, 16-bit or 32-bit Windows applications, console applications, or they could be programs that are associated with other add-on program environments including Interix (POSIX UNIX) or OS/2Windows has to examine the contents of the file to see exactly what it is.

Executable Program Types

When Windows is instructed to run an .EXE file, Windows has to examine the file to determine what type of program it represents.

All executable files start with a block of data in the standard format used by all versions of Windows and MS-DOS versions 2.0 and later (see Table 9.2 for the gory details). The file starts with the ASCII characters "MZ", followed by values that describe the location within the file of the executable instructions.

Table 9.2. Microsoft Executable File Header Format

Offset (Hex)

Bytes

Description

0000

2

ASCII characters 'MZ'

0002

2

Number of bytes in last 512-byte page of executable code

0004

2

Total number of 512-byte pages of executable code (including last page)

0006

2

Number of relocation entries

0008

2

Header size in 16-byte paragraphs

000a

2

Minimum paragraphs of memory to allocate in addition to the executable code

000c

2

Maximum paragraphs of memory to allocate in addition to the executable code

000e

2

Initial Stack Segment register (SS) value relative to start of executable

0010

2

Initial Stack Pointer (SP) value

0012

2

Checksum value for executable data

0014

4

Initial Code Segment and Instruction Pointer (CS:IP) relative to start of executable (that is, program start address)

0018

2

Offset of relocation table. For a Windows GUI or console application (that is, for anything beyond an MS-DOS application), this value is always 40 hex and points to the relocation table of the MS-DOS stub program.

0020-0019

 

(data varies depending on linker used)

001a

2

Overlay number (0 for main program)

003c

4

Offset of Windows "NE" or "PE" header from start of file; 0 if plain MS-DOS .EXE file


In the case of a true MS-DOS application, this "header" data describes the actual MS-DOS program. For Windows and console applications, the header fields point to a tiny MS-DOS program contained within the file that simply prints "This program cannot be run in DOS mode" and exits. This is called the "MS-DOS stub," and it ensures that if you attempt to run the application under MS-DOS, it will not crash the older operating system. Windows knows to look past the "stub" for a second descriptive data block called a "New Executable" (NE) or "Portable Executable" (PE) header, farther in the file.

The second header describes where within the file to find the program's executable code, its resources (dialog and text data), debugging information, and other file sections, and also indicates the CPU type and Windows subsystem to which the program belongs. The CPU type indicates the instruction set for which the program is designed, and can specify the x86 (32-bit), x86-64 (64-bit), Itanium 2, Alpha, or MIPS instruction sets. (Alpha and MIPS processors, alas, are no longer supported.) The subsystems include the following:

  • 16-bit Windows GUI application

  • 32-bit Windows GUI application

  • 64-bit Windows GUI application

  • 32-bit Windows console application

  • 64-bit Windows console application

  • OS/2 1.x console application

  • POSIX (Interix or UNIX) console application

  • Other types including device driver, DLL, and so on

Thus, between the file extension and, for .EXE files, the two header structures, Windows can determine whether it's being asked to run a script or batch file, an MS-DOS program, a Windows program, or a program designed for another supported operating system; and whether the application uses a GUI or the console window's character-oriented interface.

Program Subsystems

In addition to standard Windows GUI applications, Windows supports several sorts of console-mode applications. Windows console programs are actually full-fledged Windows programs that can use the standard Windows application programming interface (API); they just don't have graphical windows of their own. Instead, they interact through the text window of the Command Prompt window that started them.

Windows can also run programs based on other operating system standards. It does this using additional software, installed with Windows, that provide the system functions these other programs expect. This is called emulation , where Windows makes itself look and act like another operating system. Several emulation environments are available, listed in Table 9.3.

Table 9.3. Windows Emulation Subsystems

Subsystem

Description

MS-DOS

MS-DOS applications ( .COM and .EXE files) are run inside of an emulation program named NTVDM.EXE ("NT Virtual DOS Machine"), which emulates standard PC hardware, and provides the DOS and BIOS system call support expected by MS-DOS applications. The Virtual DOS Machine is described later in this chapter.

Interix (POSIX)

A POSIX-compliant (UNIX-like) environment is provided as part of the Services for UNIX package, a free download available from microsoft.com for Windows 2000 Professional, XP Professional, and the various Windows Server versions. Services for UNIX are described in Appendix A, "Windows Tool Reference."

16-bit Windows

16-bit Windows applications are supported by the "WinOldAp" system, which translates 16-bit Windows function requests into the appropriate 32-bit requests . Emulation is provided by ntvdm.exe (NT Virtual DOS Machine) and wowexec.exe (Windows on Windows); 16-bit Windows programs run inside a virtual Windows 3.1 environment provided by these programs.

OS/2 1.x

Windows NT 3.51, NT 4.0, 2000 Professional, and 2000 Server include a subsystem that runs IBM OS/2 version 1.x (character mode) applications. The OS/2 subsystem is not included in Windows XP.


Note

The 64-bit versions of Windows do not support 16-bit Windows (Windows 3.1) applications nor MS-DOS applications; the necessary emulation environments are not and will not be provided as an integral part of 64-bit Windows. If you need to use these older applications under 64-bit Windows, you must install a full-scale emulator program like VMWare or Microsoft Virtual PC, install a 16-bit or 32-bit operating system in an emulated PC, and run the old applications there.


The goal of the subsystem mechanism is that any supported program should run exactly as it would under its native operating system, yet to you, the user, it should appear and act like any other Windows console-mode application.

MS-DOS Emulation

MS-DOS applications performed disk, printer, keyboard, and mouse input/output operations through support routines provided by MS-DOS. The application would store a code number corresponding to a desired system service in a CPU hardware register, and then execute a CPU interrupt instruction, which would transfer control to DOS or the Basic Input/Output System (BIOS) routines in the lower range of system memory. These services provided a way for an application program to display text output on the screen, read characters from the keyboard and coordinates from the mouse, and to create, read, and write disk files, without the program's having to contain the code to handle the details of these operations.

However, instead of using interrupt instructions, Windows applications read and write files by calling functions in Dynamic Link Libraries provided into Windows. An interrupt instruction would simply make Windows display the message "Your program has performed an illegal operation" and terminate the program. Therefore, MS-DOS applications are run inside a "container" program called ntvdm.exe that provides code to simulate the DOS functions. Ntvdm.exe intercepts CPU interrupt instructions, and calls the appropriate Windows library functions on the program's behalf . It also contains code to mimic the MS-DOS segmented memory structure. When you attempt to run an MS-DOS application, Windows actually runs ntvdm.exe ; it reads the desired MS-DOS program into its own address space and lets it run. At this point, the MS-DOS application cannot tell it is not running on an oldfashioned PC over MS-DOS [*] .

[*] Ntvdm.exe is a descendant of SoftPC, an early 1990's PC emulator that let people run DOS and Windows 95 on Apple Macintosh computers. The original Insignia Solutions, Ltd copyright is still tucked away inside ntvdm.exe , as is the cryptic comment "NtVdm : Using Yoda on an x86 may be hazardous to your systems' health"

To achieve better performance, MS-DOS programs frequently bypassed MS-DOS's limited input/output support and took direct control of some hardware devices, including graphics adapters, parallel ports (LPT ports), and serial ports (COM ports). This was necessary because there was no standardized way of addressing graphics adapters, and on the slower computers of that era, it was not possible to process thousands of characters per second for a high-speed modem or printer when there were several layers of software involved. Windows NT, 2000, and XP do not allow any user program to have direct access to hardware devices. So, ntvdm.exe emulates the graphics adapter and COM1, COM2, LPT1, LPT2, and LPT3 hardware as well; that is, it intercepts attempts by an MS-DOS application to manipulate these hardware devices directly, and uses the appropriate Windows system functions to get the intended results.

Ultimately, the MS-DOS environment provides support for the following MS-DOS services and emulates standard hardware devices, through code built into ntvdm.exe :

  • All standard BIOS and DOS function interrupts.

  • Mouse support (MOUSE.COM) interrupts.

  • Display and keyboard hardware.

  • PC-standard timers, Programmable Interrupt Controllers, and the speaker interface.

  • Soundblaster-compatible sound adapter hardware. (No matter what sort of sound hardware your computer has, MS-DOS applications "see" a standard, low-end SoundBlaster adapter.)

  • Intel 386 memory management hardware.

  • Up to 16MB of memory, which the MS-DOS application thinks is the entirety of system memory, but which is simply a standard block of memory in ntvdm's address space.

Ntvdm's emulation works pretty well for graphics and LPT printer devices, but the serial (COM) port simulation is iffy, and network printing support is sometimes troublesome . I've run into these sorts of problems:

  • DOS programs that use network printers, such as the old DOS FoxPro database program, don't always eject a page after printing, or sometimes eject too many pages.

  • Modem software like Norton-Lambert's Close-Up remote-control software doesn't work perfectly . Data is lost between the software and the modem, resulting in slow communications and even modem hang-ups.

  • Games that attempt to use ntvdm's Sound Blaster emulation may generate hideous screeching sounds or may crash entirely.

Unfortunately, when problems like these do occur, there is little or nothing you can do about it. I keep an old laptop with Windows 95 on hand for the rare occasion that I really have to run an MS-DOS communications program that fails under Windows XP.

Special versions of some standard MS-DOS device drivers are provided with Windows XP. These are true MS-DOS style drivers, although they are specially coded to work in this emulation environment. They are loaded into the MS-DOS environment when ntvdm.exe starts up through configuration files config.nt and autoexec.nt , which are discussed later in this chapter. The additional standard services are

  • High memory access service, provided by himem.sys .

  • CD-ROM extensions, provided by mscdexnt.exe (a special version of mscdex.exe that doesn't expect to connect to a DOS-mode CD-ROM device driver).

  • Networking support (access to shared files and printers), provided by redir.exe . If you have installed a Novell NetWare client, a partial implementation of the NetWare interface is provided to DOS programs by nw16.exe and vwipxspx.exe .

  • DOS Protected Mode Interface (memory support) provided by dosx.exe , which replaces DOS's emm386.exe .

Additional support for ANSI screen output and national language support can be loaded as well; see "Configuring the MS-DOS command environment" (this chapter) for more information.

Interpreting Command-Line Syntax

Commands entered at the command prompt start with the name of the command to run, but there may be more. Any additional text items on the command line after the program name are called arguments , and they are given to the program to interpret. For example, the command

 ping mycompany.com 

runs the program ping.exe , and the extra text mycompany.com is given to ping.exe to interpret. Each program interprets its command-line arguments in its own way, according to the design of the programmer who created it.

Most programs expect to see some fundamental information like the name of a file to process or the name of a website to test. Some programs require more than one argument like this, for example, an input filename and an output filename. (The order in which they're entered usually matters! For example, the first name might always be interpreted as the name of the input file, and the second name as the name of the output file.)

Then, many programs can be made to adjust their behavior by specifying additional arguments variously called options , switches , or flags . For example

 ping www.mycompany.com 

tests the network connection to a given Internet host by sending four test data packets. You can tell ping to send eight test data packets by adding the -n option:

 ping -n 8 www.mycompany.com 

Things get decidedly hairier at this point, for there is little consistency in how these options are specified. Some programs don't want a space between an option and value; for example, the author of ping might just as well have required you to type

 ping -n8 www.mycompany.com 

Other programs, mostly those that were originally written by Microsoft or borrowed from the earlier CP/M operating system, use options that start with a slash rather than the UNIX tradition of using a dash; for example,

 dir /b 

There's simply no way to know what options are available, or how to format them, other than to look at the documentation. What you want to know is the program's command-line syntax , which is a formal way of saying "what it expects to see."

There are several possible ways to get a description of a program's command-line syntax. For a given program, which for the sake of example let's call xxx , you can try these things:

  • Type xxx /? Some programs recognize /? as a plea for help, and print out a description of the command-line syntax.

  • Type help xxx , which invokes the Windows command-line help system.

  • Click Start, Help and Support and search for xxx .

  • Search Help and Support for the string command line reference , and click the link to Command Line Reference A-Z.

  • Perform an Internet search for xxx .

There's no way to tell beforehand which of these will work; you may want to try all five.

Command-line syntax is usually described in a way that indicates what parts you have to type, what parts are optional, and what parts have to contain names or other information particular to your situation. The documentation will usually define its particular conventions somewhere, but this is a very common format:

  • boldface indicates text that you have to type literally.

  • italics indicate something that's just representative; you don't type this literally, but replace it with your own information. In some Microsoft documentation, angle brackets < > are used for this purpose also.

  • Square brackets [] enclose optional parts; you can type them or leave them out.

  • Ellipses (...) indicate that you can type more, or repeat the previous items as many times as desired.

  • The vertical bar separates a series of choices; you are to enter just one of the listed options. Sometimes, alternate choices of long sequences of options are printed on separate lines.

For example, the command to create directories (folders) can be typed as mkdir or md , and this is how Microsoft describes its syntax:

  mkdir  [  drive   :  ]  path   md  [  drive   :  ]  path  

The two lines indicate two alternate choices. The boldface mkdir or md is something that is to be typed literally. You don't type the word path literally; path just shows where you are to type the name of the folder you want to create. Drive and its following colon are optional; they can be typed, or omitted. You do have to read the description of the command to know that drive is supposed to be a single letter representing a disk drive; the syntax description can't provide that information symbolically.

This stuff may be confusing at first, but you'll soon get the hang of it, and you'll find that a glance at syntax description will convey a lot of information about what a program can and can't do.

Environment Variable Substitution

As it examines command lines that you've typed or that it has read from a batch file, cmd replaces strings of the form %name% with the value of the named environment variable. ( Environment variables are named text strings used by Windows to communicate information to programs, batch files, and scripts, and also by batch files to hold and modify data.) For example, the command

 echo %path% 

is interpreted as the command

 echo c:\windows\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem 

and echo prints out whatever is on its command line. Thus the command echo %path% displays the value of the path variable. Environment variable substitution can be used anyplace on any command line, as long as the resulting text is a valid command.

Note

Environment variable names are not case sensitive. To cmd, %path% , %Path% , and %PATH% are all the same.


Input and Output Redirection

Console programs read interactive input from the keyboard and display it on the screen. They do this through a mechanism called standard I/O streams . Each console program has available to it a stream or source of input called the standard input , and two output streams, standard output and standard error . By default, keyboard input to the console window goes to the applications standard input, and anything the application prints on the standard output or standard error streams appears in the console window, as illustrated in Figure 9.1. As you might guess, the standard output stream is used for the program's principal output, while the standard error stream is used for error messages and warnings.

Figure 9.1. Console applications have three standard input/output streams.

Note

The concept of redirectable standard I/O has a long history. It started in the Multics operating system developed at MIT in the late 1960s. In the 1970s, the developers of the UNIX operating system adopted the idea and added the < and > syntax. The 8-bit CP/M operating system "borrowed" it from UNIX, MS-DOS took it from CP/M, and Windows XP inherited it from MS-DOS. This reminds me of the Tom Lehrer song "I Got It From Agnes," but maybe we shouldn't go there.


You can think of console applications as having a sort of "plumbing." The standard I/O streams can easily be redirected , or connected, to files or other console applications. For example, the standard output stream, which usually appears in the console window, can be directed to a file using the > character on the command line. Placing >output.txt on the command line redirects what would have appeared in the console window into the file named output.txt . Similarly, the < character redirects the standard input. Placing <input.txt on the command line connects file input.txt to the standard input, so the application will read from that file instead of the keyboard. For example, the command

 sort <input.txt >output.txt 

runs the sort console application; when it reads from the standard input, it reads file input.txt , and whatever it writes to the standard output stream goes into file output.txt , as illustrated in Figure 9.2. Of course, you can specify any filenames that you want to use; it doesn't have to be input.txt or output.txt . Also, the files input.txt and output.txt will be read from and written to in the current directory, but you can control this by specifying a path as part of the redirection command; for example:

 sort <c:\myproject\rawdata\input.txt >c:\myproject\results\output.txt 

Figure 9.2. The standard I/O streams can be redirected to files.

Notice that in this command the standard error stream is not redirected. If the sort command runs into any sort of problem and prints an error message on the standard error stream, the message will appear in the console window where you can see it.

However, if you want to, you can redirect the standard error to a file. You might want to do this in a batch file that will be run when nobody is logged on, to collect any error messages in a log file so they can be printed or viewed later. To redirect the standard error stream, put 2>filename on the command line. For example, if you typed the command

 sort <input.txt >output.txt 2>error.txt 

and sort printed any error messages, they would appear in file error.txt rather than in the console window.

What's this business with the number 2? If you look back at Figures 9.1 and 9.2, you'll see that the little pipe fittings for the standard I/O streams have numbers attached to them. The standard output is designated as stream #1, and the standard error as stream #2. A number before > redirects a specific stream. So, 2>error.txt indicates that the program's standard error output stream is to be redirected into file error.txt .

You can also instruct Windows to write both the standard output and standard error streams to the same file. This will produce one file with the output of both streams mixed together. The syntax for this is 2>&1 , as in the command

 sort <input.txt >output.txt 2>&1 

It means "Stream 2 goes to the same place as stream 1." It's peculiar, but it's a very handy thing when you need it.

Finally, you should know that if the filename you specify when redirecting data output exists before you run the command, the > redirection feature erases that file. That is, after you type these three commands:

 dir >file.txt ping mycompany.com >file.txt echo This is the third command >file.txt 

file.txt will contain only one line of text, reading "This is the third command." The first command puts the output of the dir command into file.txt , and then ping overwrites that with its output, and then echo replaces that.

To get around this problem you can use the append operator >> . When you add >>filename to a command line, the standard output is added to the file if it already exists; if the file didn't exist, it is created. The commands

 dir >file.txt ping mycompany.com >>file.txt echo This is the third command >>file.txt 

will create a file named file.txt that contains the output of all three commands: first the dir listing, followed by the output of the ping command, followed by the line This is the third command from the echo command.

Table 9.4 has a complete listing of all of the redirection variations. You can use any name in the place of filename , and you can enter a plain filename or a path and filename.

Table 9.4. Input/Output Redirection Functions

Syntax

Result

< filename

Standard input is read from filename

> filename

Standard output is written to filename

1> filename

(equivalent to >filename )

2>filename

Standard error is written to filename

>> filename

Standard output is appended to filename

1>>filename

(equivalent to >>filename )

2>>filename

Standard error is appended to filename

>filename 2>&1

Standard output and standard error are both written to filename

>> filename 2>&1

Standard output and standard error are both appended to filename


Tip

You can add a space between the > or >> and the filename; it works with or without the space. You might want to get into the habit of adding a space, as it will help you if you want to use the name completion feature that is discussed later in the chapter.


Tip

If the file that you want to create has a space in its name, put quotes around the name. You can put the > or >> inside or outside of the quotes; ">filename with space" and > "filename with space" work equally well. But again, it's probably better to get in the habit of putting the > outside the quotes, so that you can use name completion.


By the way, the older command.com shell used by MS-DOS, Windows 9x, and Me does not support any of the numeric variations of output redirection, such as 2>&1 and 2> . These are part of the enhancements made to cmd.exe .

Finally, if you are familiar with the UNIX operating system and shell script programming, you should know that the << input redirection mechanism is not available in the Windows command shell.

Command Pipelines

You can direct the output of one command to the input of another using the pipeline operator ( ). The concept is illustrated in Figure 9.3. The command

Figure 9.3. The Pipeline operator ( ) connects the output of one program to the input of another.


 tasklist  findstr "winword" 

runs the Windows XP Professional tasklist program, which writes a listing of all running programs to the standard output. The pipeline operator ( ) redirects this output to the input of the findstr command, which writes to its standard output only lines containing the text string winword . This combined command thus prints a listing of just information about running instances of Microsoft Word.

You could accomplish the same thing by redirecting the output of the first command to a file, and then running the second command with input from the same file, like this:

 tasklist >filex findstr "winword" <filex delete filex 

but the pipeline mechanism actually runs the two programs simultaneously , and doesn't store the intermediate output in a disk file; the pipeline is more efficient because it all takes place in the computer's main RAM.

Pipelines aren't limited to two commands; if you need to, you can hook up several commands in sequence. For example,

 dir /b /s c:\  findstr "net"  more 

uses dir to list the entire contents of the C drive; its output is passed to findstr , which filters out only those lines containing the string net , and that output is passed to more , which displays one screen of text at a time and waits for you to press the spacebar before displaying the next screen.

Command Separators

You can type several commands on one input line using the special command separator delimiters that cmd.exe recognizes. The delimiters are described in Table 9.5.

Table 9.5. Command Separators

Syntax

Description

command1 & command2

Runs command1 , then command2 .

 

Example:
dir >listing.txt & notepad listing.txt

command1 && command2

Runs command1 , and only if it is successful (that is, if command1 sets its error status value to 0), runs command2 . If the command1 indicates an error, the remainder of the command line is discarded.

 

Example:
copy file.dat a: && copy second.dat a:

command1 command2

Runs command1 , and only if it fails (that is, if command1 sets its error status value to something other than 0), runs command2 .

 

Example:
copy file.dat a: goto copyfailed


In addition, parentheses can be used to group multiple commands. We'll talk about that later in the chapter when we cover batch file programming.

Command-Line Quoting

When a command-line program requires you to specify information such as the name of a file to process or an option to use, you usually type this information after the command name, with the items separated by spaces. For example, the delete command erases the file or files named on its command line:

 delete somefile.txt anotherfile.txt 

Unfortunately, because Windows filenames can contain spaces in the middle of the name, the command

 delete C:\Documents and Settings\brian\My Documents\a.txt 

will attempt to delete four files: C:\Documents , and , Settings\brian\My , and Documents\a.txt . To solve this problem, cmd interprets quotation marks ( " " ) to mean that the text enclosed is to be treated as part of one single argument. For example, the command

 delete "C:\Documents and Settings\brian\My Documents\a.txt" 

deletes the one indicated file. The quotation marks are not seen as part of the filename; they just keep it all together.

Note

You can also separate command-line arguments with the semicolon ( ; ) or comma ( , ), but not all programs accept them. I recommend that you don't use these characters to separate argumentsuse spaces. But, some programs do see them as separators, so, as with spaces, if you have a filename with a comma or semicolon in the name you'll have to put quotes around the name.


Escaping Special Characters

As you've already seen, the following characters have special meaning to cmd:

 < > () & , ; " 

If you need to use any of these characters as part of a command-line argument to be given to a program (for example, to have the find command search for the character > ), you need to escape the character by placing a caret ( ^ ) symbol before it. This indicates that the character is to be treated like any other character and removes its special meaning. To pass a ^ character as an argument, type ^^ .

For example, the echo command types its arguments in the Command Prompt window. The command

 echo <hello> 

would cause a problem because cmd would think that you want to redirect input from a file named hello and that you want to redirect output to...well, there is no filename after > , so cmd would print an error message. However, the command

 echo ^<hello^> 

prints <hello> .

Because the characters () < > & and ; have special meaning to cmd.exe (they are the command separators and redirection operators), if you want to specify one of these characters as part of an argument to a command-line program, you have to tell cmd to ignore its special meaning. To do this, you have to precede the character with a caret ( ^ ) character. This is called escaping it. For example, if you wanted to use the findstr command to search a file named listing.txt for lines containing & , you would have to type the command this way:

 findstr ^& listing.txt 

Without the ^ , cmd would treat the & as a command separator and would see the line as two separate commands.

To pass the ^ character itself as part of a command-line argument, you have to escape it in the same way, as in the command

 findstr ^^ listing.txt 

The first ^ means, "take the following character literally and ignore its special meaning." The second ^ is passed to findstr . This command searches file listing.txt for lines containing the caret symbol.

Editing Command Lines

One big area of improvement in cmd.exe over the old MS-DOS command.com shell is its command-line editing feature. I don't know about you, but while I'm a fast typist, my error rate is about 20%. A few letters forward, a backspace, a few more forward, another backspace . Luckily, it's very easy to edit the input to console windows. If you used the DOSKEY utility under MS-DOS, you'll find some of this familiar, but cmd.exe 's editing features are even further improved. The backspace, Delete, and left and right arrow keys work as you would expect. Table 9.6 lists additional keys you can use to edit command lines.

Table 9.6. Command-Line Editing Keys

Key

Effect

Esc

Erases the current input line and returns the cursor to the left margin.

Ctrl+left arrow

Moves the cursor one word to the left.

Ctrl+right arrow

Moves the cursor one word to the right.

Home

Moves the cursor to the beginning of the current input line.

End

Moves the cursor to the end of the current input line.

Ins

Toggles between overwrite and insert mode. In overwrite mode, keystrokes replace previously entered characters. In insert mode, keystrokes insert new characters at the cursor position sliding previous text to the right. The initial settingInsert or Overwritecan be set in the co sole window's Properties page.

F1

Copies one character from the previous command into the current command line.

F2 x

F2 followed by any character (for example, x ) retypes text from the previous command line up to and but not including the character x .

F3

Retypes the remainder of the previously entered command line, from the cursor point forward to its end.

F4 x

F4 followed by any character (for example, x ) deletes characters in the current line from the cursor point up to but not including the character x .

F5

Retypes the entire text of the previous input line into the current input line.

F6

Types Ctrl+Z; not really useful in Windows 2000 or XP.

F7

Displays a pop-up box containing the previously entered input lines. You can scroll through them with the arrow keys and press Enter to retype the selected line, or Esc to cancel.

Alt+F7

Deletes the command history.

xxx F8

F8 typed after any text will recall the most recent command from the history list whose first characters match the characters typed. Repeated F8's will search back for the next most recent matching command.

F9

Prompts you for a number n , then retypes the n th command back in the history list.

Up arrow

Recalls the previously entered line; repeated use scrolls through the last 20 or so input lines.

Down arrow

Used after the up arrow key, scrolls back down through the last few input lines.

PgUp

Recalls the oldest command in the history list.

PgDn

Recalls the most recently typed command.

Alt+Space, E

Displays the Edit menu, from which you can choose Mark, Paste, Find, or Scroll.

Paste takes whatever text is in the clipboard and "types" it into the console window.

Mark lets you select a rectangular block of text with the mouse or cursor keys; press Enter to copy the marked text to the clipboard.

We'll go into this in more detail in the next section.


The ability to use the up and down arrow keys to recall previously entered lines is especially useful, as you can quickly fix incorrectly entered commands, or simply save yourself typing when entering a series of similar commands.

Command-line editing works not only when typing commands at the command prompt itself, but also when typing text input to most console programs. However, the history list (the list of input lines that you can scroll through with the up and down arrow keys) is maintained separately for the input to the command prompt and for each program you run.

Name Completion

When you are typing command lines to cmd, you'll often need to type file and folder names. Name completion makes this easieryou can type just the first few letters of a file or folder name, press a control key, and cmd will finish typing the name for you. This is called pathname completion or filename completion , a nifty but not widely known feature that, like most of the other fun new features in cmd, Microsoft has borrowed from the UNIX operating system.

By default, the Tab key is used for both filename and pathname completion. That is, if you type a partial filename or pathname and press the Tab key, cmd will automatically add on the remainder of the first filename or folder name that matches what you've typed up to that point. If this is the correct name, you can just continue typing on the command line. This is a great timesaver!

If the name that cmd types is not the one you were looking for, you can press the Tab key again to see the next matching name. Pressing Tab repeatedly cycles through all matching names. What's more, you can hold the Shift key down while pressing Tab to cycle backward.

If cmd finds no matching file or folder name, it beeps and does nothing.

Tip

If you have to type a long pathname such as \Documents and Settings\brian\My Documents , you can use name completion for each part of the name. For this example, you could type the following:

dir \d (Tab) \b (Tab) \m (Tab)

Try this on your own computer (and use your own username instead of brian ). It's pretty slickcmd adds the required quotation marks and moves them into the correct positions automatically.


Cmd is smart enough to know that certain commands expect only a folder name. For example, if you've typed cd or rd on the command line, name completion will match only directory names and will ignore filenames. It's clever (if a bit spooky) but this mechanism only kicks in for the few commands that are "obviously" directory-only commands.

If you want to take explicit control of whether cmd should match file or folder names, you can use the TweakUI Power Toy (discussed in Chapter 6, "Tweaking and Tuning Windows") to specify different control keys for filename and pathname completion. For example, you can set the filename completion character to Ctrl+F and the pathname character to Ctrl+D. When you type Ctrl+F cmd will match only to filenames, and will ignore any potential matching subdirectory names. Likewise, Ctrl+D will match only folder names.

There are other ways to make these settings, but TweakUI is the easiest . For more information, see Microsoft Knowledge Base article number 310530.

Copy and Paste in Command Prompt Windows

Although console programs don't have the display windows and menus of ordinary Windows programs, you can still use the mouse to copy and paste text to and from Command Prompt windows.

The usual Ctrl+C shortcut doesn't work to copy text from a Command Prompt window. To copy text to the Clipboard, you have to extract a rectangular block of textyou can't select text line by line as you're used to. Position the mouse at the upper-left corner of the block of text you want, drag it down to the bottom-right corner, and then press Enter. While you're selecting text, the word Select appears in the window's title. Figure 9.4 shows how a Command Prompt window looks when selecting text.

Figure 9.4. To copy text to the Clipboard, select a block of text with the mouse and press Enter.

You can also select text using the window's System menu. Click the upper-left corner of the window or press Alt+space and then select Edit, Mark. Use the arrow keys to move the cursor to the upper-left corner of the desired area; then hold the Shift key down while moving the cursor to the lower-right corner. Press Enter to copy the selected text.

Also, in a Command Prompt window, the usual Ctrl+V shortcut doesn't perform a paste operation. You can paste text into a Command Prompt window using the System menu: press Alt+space and then select Edit, Paste. The program running in the window has to be expecting input; otherwise it's just ignored.

Tip

The keyboard shortcut for Paste is worth memorizing : Alt+space, E, P.


By the way, "cut" isn't availableonce something is typed in a Command Prompt window, it can't be removed.

If you need to run a mouse-aware MS-DOS program in a Command Prompt window, you'll want to disable the Select feature so that mouse movements will be sent to the program rather than being interpreted by the console program window. To disable the use of the mouse for copying text, select the window's Properties dialog box and uncheck Quick Edit mode, as shown in Figure 9.5.

Figure 9.5. A Command Prompt window's Properties dialog box lets you select the Quick Edit mode, Screen mode, scroll length, editing properties, and screen colors.


DOSKEY Macros

DOSKEY is a command-line helper program that originated in MS-DOS, where it provided the up-and-down arrow key command recall feature that's now a standard part of the 32-bit Windows command window. DOSKEY is also provided with Windows XP and 2000. You don't need to run DOSKEY to get the command-line editing features, but you can use it to print out the command history, and more importantly, to define macros , which are keyboard shortcuts. For example, I use the command

 doskey n=notepad 

to define n as a command macro, and henceforth I can edit a text file by typing a command line like

 n myfile.bat 

instead of having to type

 notepad myfile.bat 

Once the macro is defined, n is seen as the word notepad whenever it's typed as the first word on a command prompt line. In the long run, this really does save time and frustrationyou can't imagine how many times I've typed ntoepad instead of notepad!

By default, DOSKEY macros affect only text read by cmd.exe , that is, commands typed at the command prompt itself. You can define macros that will affect the input of specific command-line programs using the /EXENAME option. For example, the command

 doskey /exename=ftp.exe anon=anonymous 

defines anon as a macro that turns into the word anonymous when it's typed as the input to ftp.exe , the command-line File Transfer Protocol client.

Table 9.7 lists symbols that have special meaning inside a DOSKEY macro. You can use these symbols to construct macros complex enough to handle jobs that you would otherwise have to write small batch files to accomplish. With these symbols, upper/lowercase does not matter; $g and $G are treated the same.

Table 9.7. Special Symbols in DOSKEY Macros

Symbol

Function

$G

Works like > on the command line; lets you perform output redirection when the macro is run. Use $G$G to put >> in the macro, to append output.

$L

Works like < on the command line; lets you perform input redirection when the macro is run.

$B

Works like on the command line; lets you create a pipeline when the macro is run.

$T

Works like & on the command line; lets you specify several commands that are to be run in sequence when the macro is encountered .

$ n

Where n is a single digit, is replaced by the n th argument on the macro's command line.

$*

$* is replaced by all of the arguments on the macro's command line.

$$

Appears as a single $ when the command is run.


For example, after the macro definition

 doskey fs=findstr /i /c:"" .log $B more 

the command

 fs index ww3svc 

will be treated like the command

 findstr /i /c:"index" ww3svc.log  more 

which will search for a specified string in a specified log file and page the results through more .

It's important to know that unless you use $* , $1 , $2 or the other $ n symbols to explicitly tell DOSKEY to copy command-line arguments from your typed command line to the replacement line, they will be discarded. For example, with the definition

 doskey n=notepad 

the command

 n myfile.txt 

will open Notepad but the filename will not be seen. You have to define the macro this way:

 doskey n=notepad $* 

to ensure that any arguments on the command line after n are passed along to notepad .

The command doskey /macros:all will list all defined macros.

To load your favorite DOSKEY macros every time you open a Command Prompt window, it won't help to put the DOSKEY command in autoexec.bat (which is ignored) or \windows\system32\autoexec.nt (which is used only by the MS-DOS emulation system). Instead, you have to put the desired macro definitions into a text file (one macro per line with the format name=replacement ) and make an entry in the Registry to tell cmd.exe to load these settings every time it starts up.

You can define DOSKEY macros for all users by setting a Registry value named AutoRun under key HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor , or just for yourself by setting value AutoRun under HKEY_CURRENT_USER\Software\Microsoft\Command Processor . The entry should be a String ( REG_SZ ) or Expandable String ( REG_EXPAND_SZ ) with the name AutoRun and the value

 doskey /macrofile="  full path to macro definition file  " 

A helpful shortcut here is to define the value as an Expandable String ( REG_EXPAND_SZ ) under HKEY_CURRENT_USER ... with the text

 doskey /macrofile="%userprofile%\doskey.macros" 

You can then create file doskey.macros in your own profile folder (for example, in C:\Documents and Settings\Brian ). My own doskey.macros file contains the following entries:

[View full width]
 
[View full width]
n=notepad $* e=explorer. home=cd /d %userprofile% desktop=cd /d %userprofile%\Desktop macdef=start /wait "" notepad "%userprofile%\doskey.macros" $T doskey /reinstall $T doskey /macrofile="%userprofile%\doskey.macros" u=cd /d d:\project

Here's what they do:

  • Macro n lets me run Notepad with one character.

  • Macro e pops open a Windows Explorer window in the current directory.

  • Home sets the current directory to my Windows profile folder and desktop sets the current directory to my Desktop folder.

  • Macdef (whose definition is displayed on two lines here but is actually typed all on one line in doskey.macros ) lets me modify my macro definitions and have the changes take effect without having to close the Command Prompt window and open a new one. It opens the macro definition file for editing, clears the defined macros, and then reloads the definitions. Start /wait is used here so that DOSKEY doesn't run until after Notepad exits.

  • The last macro u is a quick shortcut to a commonly used folder. I add and delete macros like this all the time, as my work projects come and go. They save a lot of typing.

Note

The version of DOSKEY provided with Windows 2000 and XP works only in the 32-bit command prompt environment, not the 16-bit emulated MS-DOS environment. Running DOSKEY inside autoexec.nt or after running command.com has no effect. This means that the up and down arrow keys will not recall commands in the 16-bit command shell.

The version of DOSKEY provided with Windows 98 and Me is the original 16-bit version that does work inside the command.com shell. It's most effectively loaded in autoexec.bat , before Windows is loaded.


For a full description of all of DOSKEY's features, type

 help doskey  more 

at the command prompt.

Command Extensions

Under Windows 2000 and XP, lines into a Command Prompt window or listed in a batch file are processed by cmd.exe , which is known as the command shell or command-line processor. It performs the same function that command.com did under DOS and earlier versions of Windows, but it has been expanded and includes many additional features. If you haven't used the command-line environment since the days of MS-DOS, and especially if you write batch files, you need to know about cmd's important and useful enhancements. Table 9.8 lists some of the ways that cmd handles commands differently than command.com . For more information, search Windows Help for "cmd."

Table 9.8. Command Extensions provided by cmd.exe

Command

Enhancement

Cd

The cd (Change Directory) command can change the current drive letter as well as the current directory. For example,

 
 cd /d w:\serverfolder 

 

changes the drive letter to W: as well as changing the current directory to \serverfolder . This is especially useful in batch files where you may have an environment variable that contains a drive letter and path, as in cd /d %userprofile% .

pushd path popd

Pushd is a new command that also changes the current directory (or drive and directory), but also "remembers" the previous drive and directory. Popd returns to the previous drive and directory. Pushd and popd commands can be nestedthree pushds followed by three popds get you back to where you started.

Pushd can take a network path name as its argument, for example, pushd \\server\do files . This will automatically map a drive letter to the network path, starting with drive z: and working backwards .

for

The for command has been extensively enhanced and now has the ability to scan directories, scan directories recursively, iterate through number ranges, scan the lines of a file or the output of a command-line program, and more. Special substitution operators let you extract specific parts of the any matched filenames or tokens. For more information type the command help for more .

set

The set command, which lets you define environment variables, has been enhanced to let you perform mathematical calculations on environment variables, extract substrings, and prompt for user input. For more details, type help set more .

call

The batch file command call can now call subroutines defined within the same batch file, using the syntax call : label [ arguments ... ].

goto

The batch file command goto can now jump directly to the end of the file, to terminate the batch procedure or return from the batch subroutine, with the syntax goto :EOF .

setlocal endlocal

In a batch file, setlocal saves a copy of the environment variables, and subsequent changes to or additions to the environment will not persist after the batch file exits. An endlocal command inside the batch file will restore all environment variables to their value at the time of setlocal .

 

Setlocal can also be used to enable and disable all of these command extensions, and to enable or disable delayed expansion, a complex but important feature that comes into play when you write complex batch files. Delayed expansion is disabled by default, and must be enabled in a batch file with the command setlocal enabledelayedexpansion . Delayed expansion is described in more detail shortly.


In addition, input and output redirection operators have been enhanced, as described earlier in this chapter under "Input and Output Redirection." Multiple commands can be typed on one command line, using the separators discussed earlier under "Command Separators."

Printing in the Command-Line Environment

Windows applications generate printed output through calls to the Windows programming interface. Output is page oriented; that is, applications generate output by describing to Windows what to draw on successive whole pages of paper. Output is graphical in nature; lines, images, and text are all drawn pixel by pixel. The application doesn't know how to tell the printer how to draw these things; it simply tells Windows what it wants drawn, and Windows communicates this to a printer driver that sends the appropriate manufacturer-specific commands to the printer.

Console applications are distinctly different. Windows console applications have no concept of formatting; they simply spit text out character by character, line after line. The output from these programs is plain text, with no font, pagination or formatting information whatsoever. If you used MS-DOS you may be familiar with the technique of directing output to the lpt1 device, as in the command

 dir >lpt1 

On Windows, this does direct the directory listing to device LPT1, your computer's parallel port device, but there are several reasons this might not produce the listing you intended:

  • If you are using a laser or inkjet printer, this inherently page-oriented device will not "kick out" the printout until it receives a form-feed instruction. Most likely, nothing will come out until you try to print the next document. And then, the page margins and default font will likely be unsatisfactory.

  • If your printer is connected to a USB port, this won't work at all unless you share the printer on your network, and then use the net command to redirect LPT1 output to the printer via the network share.

  • Many cheap inkjet and laser printers cannot interpret ASCII text directly and will generate no output at all. Postscript printers will likely simply generate an error page. Only dot-matrix printers and page printers with a built-in page-description language (for example, printers with Hewlett-Packard PCL support) will generate valid text.

The best way to get printed output from Windows console applications is to redirect their output to a file on your hard disk, and then open and print the file with Notepad or your favorite word processor.

For example, to get a printed listing of the files in your My Documents folder, you might open a command prompt window and issue these commands:

 cd My Documents dir >listing.txt notepad listing.txt 

You can then print this listing from within Notepad. To get printed output from a batch file, you can use this command line:

 notepad /p listing.txt 

which makes Notepad open the file, print it, and then immediately exit, without any manual interaction. The printout will use Notepad's default font and margins, which you should set beforehand.

MS-DOS applications like WordPerfect take full responsibility for communicating with the printer, and want to send specific formatting codes to the printer. The MS-DOS emulation subsystem simply passes these codes directly to the printer, so you must configure the MS-DOS program to tell it what make and model printer you are using. The issues I discussed previously still apply: USB printers and inexpensive page printers will likely not work at all.

Some MS-DOS applications can use printers shared on your network, as long as the share names of the devices are 8 characters in length or less, and the names of the computers are 15 characters in length or less. For example, WordPerfect 5.1 can be told to use network printers given the printer's network share name, which will look something like \\mycomputer\laserjet .

If your MS-DOS application doesn't know explicitly how to use networked printers, you may also be able to let it use a network printer by redirecting an MS-DOS LPT printer port to a network printer. You must use an LPT port number for which there is no physical LPT port on your computer. Because most computers do have an LPT1 parallel printer port, you must use LPT2, LPT3, up to LPT9. (Some MS-DOS programs can only use printers up to LPT3.) The command

 net use lpt2: \mycomputer\laserjet 

makes the MS-DOS LPT2 device point to the shared printer named laserjet on the computer named mycomputer . Once this is done, you can configure your MS-DOS application to print to LPT2.

You can even use this technique to let MS-DOS applications print to USB printers attached to your own computer. Set up sharing on your USB printer, and then issue the net use command using the name of your own computer on the command line. Again, remember that this will work only if the USB printer can accept raw text, or if it uses a page description language (formatting code set) that your MS-DOS application knows how to use.

To stop redirecting an LPT port to a network printer, issue the command

 net use lpt2: /d 

substituting lpt3 for lpt2 if that's what you were using.

Print Screen

On Windows XP, the MS-DOS Print Screen function does not work as it did in the real MS-DOS. When an MS-DOS program is running in window mode, the PrtScr key works just as it normally does in Windows: It copies a bitmap picture of the screen or current window to the Clipboard. You have to paste the bitmap into a document (in, say, Word or WordPad), and then print that document.

When an MS-DOS program is running in full-screen mode, the PrtScr key still doesn't send the screen to the printer. Instead, it copies the screen's text to the Clipboard. To print it, again, you'll need to paste the text into a document and print it as a separate step.


Stopping Runaway Programs

Occasionally you'll type a command that starts spewing page after page of text to the screen, or one that displays some sort of ominous warning about making a change to Windows that can't be undone, and you'll want to stop itpronto.

Most command-line programs will quit if you press Ctrl+C. If that doesn't work, Ctrl+Break often works. As a last resort, you can simply close the Command Prompt window by clicking its close box in the upper-right corner. This will kill the program in at most a few seconds.

On Windows XP Professional, you may also find the tasklist and taskkill command-line programs useful. Type tasklist to get a list of active programs. This will display something like this:

 Image Name                   PID Session Name     Session#    Mem Usage ========================= ====== ================ ======== ============ System Idle Process            0 Console                 0         16 K System                         4 Console                 0        216 K smss.exe                     876 Console                 0        372 K csrss.exe                    924 Console                 0      3,320 K winlogon.exe                 948 Console                 0      5,584 K setiathome.exe              1072 Console                 0     20,252 K ... winword.exe                 2756 Console                 0     22,784 K cmd.exe                     1904 Console                 0      4,320 K tasklist.exe                 488 Console                 0      4,148 K 

The PID column contains the Process Identification number (PID) of each running program. You can kill a program with the command

 taskkill /force /pid  nnn  

with the PID of the program you want to stop in place of nnn .




Upgrading and Repairing Microsoft Windows
Upgrading and Repairing Microsoft Windows (2nd Edition)
ISBN: 0789736950
EAN: 2147483647
Year: 2005
Pages: 128

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net