10 Keys to Command Shell Scripting

4. Make Sure the Executables You Want Are Available
If your script relies on programs that aren't a part of the standard OS installation, you must make sure that any such programs are available. You should also document these dependencies in your scripts. One way to ensure executables are available is to put them in the same directory as the script. Then you can run them by using the syntax

"%  ~dp0exename"   ... 

where exename is the name of the executable you want to run. The %~dp0 syntax returns the drive, path, and filename of the current script without quotes. Enclosing the entire string in quotes ensures that the script will still work even if the filename or the directory the script is in contains quotes.

5. Use Double Quotes Correctly
Double quotes (") seem to be a common source of confusion for shell-script writers. Quotes are simply a way of identifying command-line arguments that contain spaces. For example, although it might look correct, the command line

dir C:\Program Files 

gives the Dir command two arguments: C:\Program and Files. To indicate that you intend C:\Program Files to be a single argument (including the space), enclose it in double quotes:

dir "C:\Program Files" 

The quotation marks aren't part of the directory name. They tell the Dir command that the text between them is one argument.

Shell scripts also support command-line arguments. To access a script's command-line arguments, use the notation %n (where n is a number 0 through 9). This notation is called a replaceable parameter (or simply a parameter). For example, the script will replace the %1 parameter with the first command-line argument, %2 with the second argument, and so forth. In addition to %1 through %9, %0 is replaced with the script's name, and %* is replaced with the script's entire command line (not including the script name). I mention command-line arguments here because when Cmd.exe replaces the %1 through %9 parameters with the corresponding command-line arguments, it leaves the double quotes if they're in the argument. This fact leads to a simple observation: A script parameter will always be contained in double quotes if it contains spaces. The following simple rules are based on this observation, and if you follow them carefully, you'll virtually eliminate quoting problems from your shell scripts.

• Don't put quotes around script parameters (%1 through %9) because they might already contain quotes. If you need to use a parameter with the If command, use characters other than double quotes (e.g., curly braces) to avoid syntax errors. The following script line will work even if the first parameter (%1) contains quotes:

If {%1}=={} Goto :HELP 

The exception to this rule is when you use the syntax %~n to remove a parameter's quotes (which I explain in the next rule).

• Don't include quotes in the contents of an environment variable. Environment variables can contain spaces without needing quotes. If you need to copy a parameter into a variable, use the syntax %~n (where n is a number 1 through 9), which returns the parameter without quotes. For example, the line

Set DATAFILE=%  ~1 

will copy the script's first parameter ( without quotes) into the variable DATAFILE. The exception to this rule is if you're creating quoted text that will be passed to another command.

• Remember to put quotes around environment variables if needed. For example, consider the following script lines:

Set TARGET=% ~2
Copy %1 "%TARGET%" 

The first of these lines copies the script's second argument into the TARGET variable, removing the quotes. The second line is syntactically valid because the %1 parameter is already enclosed in quotes if it contains spaces, and the TARGET variable needs quotes because it might contain spaces.

   Previous  1  [2]  3  Next