Batch/Command files are far from gone...Parameter Processing
If you are a regular reader, then you know I've been working on a major SharePoint/MOSS upgrade the last couple of months. It's finally winding down to a close and should finish up this week.
One of my duties as part of this process has been to produce a series of scripts that automate the upgrade, as much as possible. Unfortunately, PowerShell wasn't an option here, as the client couldn't deploy PowerShell in a timely manner given the constraints under which they operate.
So...out come the batch files!
It's worthwhile noting that if you are deploying RODCs (Read-Only Domain Controllers) in Windows Server 2008 - you will still need to know how to write these! PowerShell can't be installed on RODCs due to its dependence on the .NET Framework.
There are a couple of things about batch files that are really cool - but those things are few and far between! When you start to take advantage of the cool features, your batch files start to look like spaghetti code (because they are) and they become quite difficult to read.
Here is a feature I've used extensively recently:
set PRESCAN=%PRESCAN:"=%
How obvious is that, eh? What this does is set an environment variable named PRESCAN to itself - after all quotations marks have been stripped out. This is something you need to be able to do when an executable file name is passed in as a variable to a batch file. If the file name has spaces in it, then the user of the batch file will have to quote the file name. And one of the, uh, odd things that the batch file processor does not do for you is strip those off. So if the user enters:
somefile.cmd "C:\Program Files\A Utility\util.exe"
Then the string received by the batch files for parameter 1 is "C:\Program Files\A Utility\util.exe" - quotes and all. If the user enters:
somefile.cmd C:\Program Files\A Utility\util.exe
Then the string received by the batch file for parameter 1 is C:\Program - with no quotes.
Ouch.
Now, if you try to use the filename with quotes in it - many features of batch files don't work. You can't execute the program, you can't use "IF EXIST", etc. So, you have to strip them off.
You also need some way to determine the user specified a value for a parameter. If they didn't, you may want to substitute a reasonable default (or generate an error message if the value should be requried). "IF DEFINED" is to the rescue, but it has quirks too.
Using these pieces of information, we've got two possibilities now. Let me show you a couple of examples:
SET PRESCAN=%7
If DEFINED PRESCAN goto :cleanPRESCAN
Set PRESCAN=C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\prescan.exe
echo PRESCAN (parameter 7) not defined. Trying %PRESCAN%
:cleanPRESCAN
REM strip any quotation marks off
set PRESCAN=%PRESCAN:"=%
IF EXIST %PRESCAN% GOTO :gotPRESCAN
echo Specified PRESCAN file does not exist. Aborting.
goto :EOF
:gotPRESCAN
echo.
echo Will use PRESCAN file: %PRESCAN%
echo.
Note that in this example, the user may or may not specify a value for the parameter. If they don't, a reasonable default is applied. If they do, quotes are stripped out of the file name. The the existence of the file is checked and if it is present, processing continues.
REM
REM Process parameter 5 (name of the database server and instance)
REM
if "x%5" == "x" GOTO :noDBSERVER
set DBSERVER=%5
goto :gotDBSERVER
:noDBSERVER
SET /p DBSERVER="Enter the name of the database server (and instance if applicable): "
if NOT DEFINED DBSERVER (
echo You entered an empty database server name. Aborting.
goto :EOF
)
:gotDBSERVER
Now, in this case, a different technique is used to determine whether or not a value has been provided by the user (as the desired outcome is different). If the user hasn't entered a value as a parameter, then the user is prompted to enter a value. If they do not, the program aborts.
Using protected input like this is a key difference between an "enterprise quality script" and something you just "see on the Internet". One is suitable for production use. The other is suitable for hacking around. Which kind are YOUR scripts?
Until next time...
Thanks for reading! If there are topics you would like to see covered in this blog, please send me an e-mail or leave a note in one of the forums.