| Downloads |
|---|
| 46648.zip |
A well-written script can cut minutes or hours off performing a repetitive task. On the downside, the biggest fear of scriptwriters is probably that one of their scripts might damage something. A script that's executed on the wrong node, by the wrong user, with the wrong parameters, or at the wrong time can make unwanted changes before you even recognize your error. If a script you've written performs queries or builds reports, an accidental launch probably results only in bogus or unwanted output. But if a script performs modifications or deletions, as my file deletion scripts do, an accidental double-click could spell disaster. Here are some tips for making such scripts safer.
Verify Environment Variables
Many years ago, when I was a junior systems administrator new to scripting, I launched a script on the wrong node. The senior administrator glanced over my shoulder, saw what had happened, and killed the script run. Fortunately, my error didn't do any damage, but it made me much more aware of what could have happened.
If you want to prevent accidental script launches on the wrong node, by the wrong user, or even on the wrong date, add the appropriate snippets from Listing A to the top of your script. Listing A includes code that tests for node, username, and date and aborts the script if the incorrect environment variables are found. If someone tries to run your script on the wrong node, by the wrong user, or on the wrong date, the script exits. Obviously, this precaution doesn't prevent another administrator from modifying the code to run the script on a different node or in a different user context, but it can eliminate many potential accidents.
Verify a Parameter
Another way to prevent accidental script runs is to put a "safety switch" on your scripts in the form of a parameter entered at runtime. If the script checks for a parameter at runtime and doesn't find the correct parameter, you can have the script echo a warning or, if appropriate, default into a nondestructive list mode.
I use the latter approach in DeleteFilesByExtension.bat, DeleteOlderFiles.bat, and DeleteLargeFiles.bat. The scripts run in list mode by default. In that mode, the scripts report on what would have been deleted if they'd been run in Delete mode, but they perform no actual deletions. When the script finds the correct parameter, the script switches to Delete mode and performs the deletions. This precaution makes an accidental double-click or unintended script launch a non-event.
Rename the Script
Like many hard-core scriptwriters, I like to keep every script I've created so I can leverage sections of the code in future scripts. But this useful resource is also a potential minefield, because when right-clicking scripts to edit or view the code, you might accidentally launch the script.
If you have a script that's intended for one-time use only, you can use a renaming trick to effectively disable it after it's been run. Add the following code to the end of the script:
Move "%0" "%0.txt"
This code renames the script after it runs by giving it a .txt extension. The renamed script is in a benign, non-executable state but still lets you to find it by name using the Windows search capability or another search utility.
Be aware that this technique produces the trivial error message "The batch file cannot be found" because the script file has been renamed and isn't where Windows expects to find it after it's been run. This error message doesn't indicate a problem, and you'll see that the script has been renamed successfully.
