| Downloads |
|---|
| 48748.zip |
Dealing with spaces in command paths can be a hassle. We've all had the experience of sending a script to a colleague at another site and having the script fail because of spaces in paths to input files, output files, commands, or even the script itself. Even if you've tenaciously eliminated path spaces in your script environment, someone who deploys a script at another location might reintroduce spaces in the paths. The optimal solution is to code your scripts so that they aren't affected by the addition of path spaces. If you spend a few minutes to do this at the script-development stage, then test the script by introducing spaces in the debugging stage, you'll be rewarded with a more stable script that can work anywhere and won't require changes to "fix it" to work with spaces.
Problems with spaces in the paths to input or output files are fairly easy to solve. For input files, you can use the For command with the usebackq option to handle input files, as this example shows:
For /F "usebackq tokens=*"
%%i in ("d:\input file.txt") Do Echo %%i
For output files, you can surround the file path with double quotes to handle spaces, like this:
Echo Output>>"D:\output file.txt"
Dealing with spaces in command paths is a bit more difficult. Often commands such as Diruse that work fine outside a For command can fail when embedded within a For command. For example, this command will execute successfully:
"C:\Resource Kit\Diruse.exe" "\\ServerA\Share123"
But this similar command will fail:
For /F tokens=*" %%i in
('"C:\Resource Kit\ Diruse.exe"
"\\ServerA\Share123"')
Do Echo %%i
Double-quoting the path to the command and to the target path inside a For command has caused the failure.
Because we want to make our scripts transferable, we need to assume that the commands they contain might end up with a space in the path and thus make them goof-proof, so that they'll succeed no matter who deploys them or where they're deployed. One way to address this problem is to switch the command paths to an ISO 9660 8.3 filenaming format. The following code performs the 8.3 conversion:
Set DirusePath=
C:\Resource Kit\Diruse.exe
For /F "tokens=*" %%i in
("%DirusePath%")
Do Set DirusePath=%% ~dpnxsi
For /F "tokens=*" %%i in
('%DirusePath%
"\\ServerA\Share123"')
Do Echo %%i
After the utility path is converted to an 8.3 format, you can use it in a script without worrying about spaces in the path. The path will return correct results when used inside a For command.
Path-space problems can also occur when you've coded your script to self-locate. Self-locating basically means you use the %0 environment variable to determine the directory that your script resides in. This technique is commonly used to look for input files or to create output files in the same path where the script resides without needing to specify that path in the variables you set at the beginning of the script.
If your script resides in a path that has spaces, you can use either the input and output file methods I described earlier or the %~dpnxsi variable approach, which Listing A shows, to fix path-space problems in self-locating code.
Another potential gotcha when dealing with spaces is the possibility that a script user will encapsulate the path used in a Set command in double quotes when you've coded the script to work without double quotes. In this case, adding double quotes can result in duplicate double quotes and a script failure. In ReplicationTest, I coded around this problem by using a string substitution to strip off the double quotes, which Listing B shows, then coded them back in later in the script. This technique ensures that the script works correctly regardless of whether the user enters the pathname in double quotes.
