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.