Let the command shell window do all the work
Do you repeatedly use certain commands in your job? Rather than constantly retyping those commands, would you rather have those commands preloaded and available for use each time you open a command shell window? This capability isn't just wishful thinking. You can preload basic commands quite easily by taking advantage of the script CommandShellLoader.vbs. After you use this script to preload your commands, accessing and running them can be as simple as pressing your keyboard's Up Arrow or Down Arrow key, then pressing Enter. Even better, you can use one version of the script to preload one command shell window with the commands you use to manage users and groups, another version of the script to preload a window with the commands you use to manage share, file, and folder permissions, and so on. To keep track of the multiple commands you're running, the script changes the command shell window's color each time it runs.
CommandShellLoader.vbs uses Windows Script Host (WSH) and NTFS file streams to achieve these feats. To use this script, you need to know how to preload commands and change the color of command shell windows. Armed with this knowledge, you can adapt the script to preload the commands that you use most often.
Since the days of DOS and the Doskey command, administrators have enjoyed the convenience of using the Up Arrow and Down Arrow keys to access previously run commands. You can take advantage of this DOS feature by preloading commands that you use most often. To preload commands, you simply open a command shell window and run those commands so that they're in the command buffer.
To programmatically preload commands, you can use WSH, as the code in Listing 1 shows. (You can also use the Microsoft ScriptIt utility, which Microsoft doesn't support.) This VBScript code uses the WshShell object and its SendKeys method to preload the Dir command and the Ping /? command. The code opens a command shell window, enters the Dir and Ping /? commands, then executes them. Note the frequent use of the line
in Listing 1. This line is equivalent to pressing the Enter key. After you run the code in Listing 1, try pressing the Up Arrow key. As you can see, pressing the Up Arrow key reenters the commands in the command shell window, making them available for reuse without retyping them.
Let's look at a real-world example of how you can take advantage of preloading commands. At my job, I frequently perform user and group management tasks. I often use the Microsoft Windows 2000 Server Resource Kit's Findgrp tool to determine a user's group memberships. I use the Findgrp tool for two resource domains (Sales and Production) and two user domains (South and North). So, I use the following Findgrp commands:
Findgrp Sales North\UserID
Findgrp Production South\UserID
Findgrp Production North\UserID
where UserID is the ID of the user for whom I want to determine group membership. The only part that changes in these Findgrp commands is the user ID, so the Findgrp command works well for preloading. I preload the first section of the command (e.g., Findgrp Sales South\), then whenever I need to determine a user's membership, I press the Up Arrow key, type the user's ID, and press Enter to run the command without having to type the first section again.
In the Findgrp command, the element that changes is conveniently at the end of the command. How do you handle situations in which the changeable element falls in the middle of the command? You can still preload such commands if you use a bit of creativity. Take, for example, the Local command, which I often use to display the members of local groups. The syntax that I follow is
domain_name | \\server
where group_name is the name of the group for which I want to see the members, domain_name is the name of the domain in which the group resides, and \\server is my server's name. Although the domain_name and \\server elements are static, the group_name element continually changes.
The code in Listing 2 shows how you can preload this command. As the code at callout A in Listing 2 shows, you first preload a command that sets the localgrp variable, then preload the Local command, which uses the localgrp variable. After you preload these commands, you simply have to press the Up Arrow key twice to access the "Set localgrp=" entry, enter the group name, press Enter, press the Down Arrow key to get back to the Local %localgrp% North command, then press Enter again. Because you set the localgrp variable to the group's name, the OS will substitute the specified group's name when it runs the command.
Changing Window Colors
I often have several command shell windows open simultaneously. Occasionally, I accidentally close the wrong window, killing a script that was still running. To help differentiate between tasks, I decided to launch windows that have different background colors. You can modify the background color of a command shell window in several ways:
- You can manually change the background or text colors by right-clicking the command shell window's title bar, selecting Properties, then clicking the Color tab.
- You can manually change the color settings when you create a shortcut that points to the \%systemroot%\system32\cmd.exe directory.
- You can programmatically change the color settings with Windows shell scripting's Color command.
I knew that I didn't want to take the time to modify a window's properties each time I launched a command shell window. Nor did I want to have 10 shortcuts for different colored shell windows on my desktop. So, I decided to create code that would use the Color command to launch a different colored window each time I ran the code.
Figure 1 shows the Color command's syntax, which you can access online by running the command
This syntax shows that the first hexadecimal digit in the two-number scheme specifies the background color. By incrementing that number by the hex value 10, you can change the background color as follows:
- 07—Black background with white text
- 17—Blue background with white text
- 27—Green background with white text
- 37—Aqua background with white text
- 47—Red background with white text
- 57—Purple background with white text
- 67—Yellow background with white text
- 77—White background with white text
- 87—Gray background with white text
- 97—Light blue background with white text
The 77 combination poses a problem. If you specify this color combination, the Color command errors out and the window color defaults to the standard window color scheme, which would probably duplicate a background color already in use. Keeping this problem in mind, I determined that the code had to perform these steps:
- Store and capture the color number for the most recent command shell window opened.
- If that number doesn't exist (e.g., you're running the script for the first time), set the color number to 07 and open a command shell window.
- If the number exists, increment it by the hex value 10.
- If the incremented number is greater than 97, reset the color number to 07 and open a command shell window.
- If the incremented number is less than or equal to 97, open a command shell window in the specified color.
- If the incremented number is equal to 77, change it to 87 and open a command shell window.
To perform these steps, the code needs to maintain a record of the most recent color setting. You can store the most recent color setting in several ways, including storing the setting in the registry, an environment variable, a text file, or an NTFS file stream. I chose to use an NTFS file stream.
NTFS supports multiple data streams in files. The stream with which most administrators are familiar is the visible unnamed stream. Besides the unnamed stream, NTFS supports hidden named streams. You can create hidden named streams and store data in them. (For detailed information about this handy scripting tool, see the article "How to Take Advantage of the Hidden Streams in Your Scripts," http://www.winscriptingsolutions .com, InstantDoc ID 15845.)
To use hidden streams, you must have NTFS. However, if you have a FAT or FAT32 file system, you can still use the code I'm about to show you. You just need to change the code so that it creates a text file in the Temp folder instead of creating a hidden stream associated with the Temp folder. Another alternative is to convert a FAT partition to NTFS.
As Listing 3 shows, the code you use to create a hidden stream is similar to the code you use to create a text file. After you create an instance of the Scripting Runtime Library's FileSystemObject object, you use that object's CreateTextFile method to create a hidden stream named cmdno.txt in the Temp folder. If you were to replace the colon that precedes the filename cmdno.txt with a backslash (\), you'd create a text file named cmdno.txt in the Temp folder. The colon tells the OS to create a hidden stream rather than a text file. After creating the hidden stream, the code uses the WriteLine method to write the value 07 to the hidden stream. Finally, the code uses the Close method to close the stream.
Reading a value in an existing hidden stream is as easy as writing it. As the code in Listing 4 shows, you use the OpenTextFile method to open the hidden stream and the ReadLine method to read the stream's data.
Putting It All Together
CommandShellLoader.vbs combines the code that preloads the Findgrp and Local commands and the code that changes the background color of the command shell window. This script runs on Windows XP, Win2K, and Windows NT 4.0 machines that have WSH 5.6 installed. You can adapt this script so that it preloads your favorite commands. Simply follow these steps:
- Review the function-key options available for the Doskey command by running the command
- Make a list of the commands you want to preload. If the list is long, you can divide the commands into logical groups and put each logical group in a separate script. For example, you can put all the commands you use to manage users and groups in one script and put those commands you use to manage share, file, and folder permissions in another script.
- Determine the syntax for the commands you want to preload and test these commands. Make sure that the commands don't perform unintended tasks. In addition, make sure that the command errors out quickly in case something goes wrong—you don't want to have to wait a long time for the script to quit.
- Download CommandShellLoader.vbs from the Code Library on the Windows Scripting Solutions Web site (http://www.winscripting solutions.com). Place the .vbs file in the directory in which you store your scripts. You can run the script from either a local machine or a network share.
- Adapt CommandShellLoader.vbs so that it preloads the commands you selected and tested in Steps 2 and 3.
- Place a shortcut to the CommandShellLoader.vbs in your Quick Launch folder so that you can easily access the script.
In addition to reviewing the function-key options, take a look at the Doskey command's many helpful switches. CommandShellLoader.vbs uses the /reinstall switch to clear the command history buffer before preloading the specified commands. The script also uses the /listsize switch to set the size of the command history buffer to 50 commands. A buffer of this size is adequate for most environments. If you have more than 50 commands to preload, to optimize performance, I recommend that you divide the commands into logical groups (see Step 2) rather than increase the buffer size.
A Time-Saving Tool
If you want to significantly reduce the number of keystrokes needed to launch your favorite commands, take the time to adapt CommandShellLoader.vbs. In the long run, you'll not only save time but also avoid the tedium of having to retype the same commands over and over again.