10 Keys to Command Shell Scripting

Shell scripts are plain-text files that a command shell interprets as a series of commands to be executed in sequence. Shell scripts have a long history: The Command.com shell in MSDOS has supported simple batch-file scripting since the early 1980s. Released with Windows NT in 1993, the text-based Cmd.exe command shell supports a script language similar to the batch language in Command.com. Despite its age, Cmd.exe shell scripting is still a useful tool in the IT professional's arsenal. For example, a simple shell script with a For command can transform a command that works with only one computer or username at a time on the command line into a command that can step through a text file and execute the command for each line in the file. Because shell scripts are plain-text files that contain a series of commands, they are easy to create, modify, and understand. However, these scripts' simplicity can also be a liability. A carelessly written shell script can cause potentially serious problems. I've seen shell scripts that make incorrect assumptions about the underlying OS or environment that, at best, prevent them from working correctly, or at worst, wreak havoc on an unsuspecting system. To help you avoid such problems, I've written the following set of 10 guidelines for creating more robust scripts that can work correctly in various environments.

1. Use Environment Variables When Possible
When you use a variable in a script, you enclose the variable's name between percent signs (%), and when the shell script runs, the percent signs and the text between them will be replaced with the variable's data. Using variables makes the script's code more generic—it has a better chance of running successfully on different computers. For example, you should never "hard-code" the Windows installation directory name in a shell script. Instead, you should use the SystemRoot variable, which will always point to theWindows installation directory. So, the command

Echo %SystemRoot% 

will display the contents of SystemRoot (i.e., the Windows installation directory).

In several cases, I've seen shell scripts that used C:\WINDOWS to refer to the Windows installation directory. If Windows isn't installed in C:\WINDOWS (e.g.,Windows 2000 and earlier are installed in \WINNT), the script won't work properly. Environment variables make life easier for programmers and script writers.

To see a list of environment variables, type the Set command at a command prompt. Some variables don't appear in the list generated by the Set command because they're dynamically generated by Cmd.exe. Table 1 shows a list of these variables. As with other environment variables, enclose these variables between percent signs. For example, the following line in a script will display the current date and time:

Echo %DATE% %TIME% 

2. Don't Expect Legacy Command.com Batch Files to Work in Cmd.exe
If you're accustomed to writing batch files for the MS-DOS or Windows 9x/Me platforms, be aware that some batch-file commands you're used to don't exist in the newest versions of Windows. The Choice and Deltree commands are the two most common examples. Review your old batch files to make sure they work correctly in a Cmd.exe window. Table 2 shows some suggested replacements for Choice and Deltree. Most of these replacements have a different-syntax than the commands they're replacing, so you'll need to modify your scripts accordingly.

3. Use the .cmd Extension for Cmd.exe Shell Scripts
Command.com batch files require the .bat file extension. Cmd.exe can also use the .bat extension, but in Cmd.exe's more powerful scripting language, many commands aren't compatible with Command.com. Thus, a .bat file that you design to work with Cmd.exe might fail if a user tries to execute it in Command.com (e.g., in Windows 98). One way to avoid this potential problem is to use .cmd as a shell script extension. Because Command.com doesn't recognize the .cmd extension, it simply won't execute a batch file if the filename ends with .cmd.