You guys are missing the point...

If you work for one company and have total control, needing a variable place to put your scripts and config files is probably not necessary. However, if you write a script that it going to be used at many different companies, you need to build-in some flexibility to account for the control you don't have.

Step 1 - decide on a folder structure that you PREFER. I use:
C:\Local for my config files
C:\local\bin for my scripts and utilities (kix32.exe, *.kix, *.bat, blat.exe, etc)
Create this folder structure and populate it with the files necessary.

Step 2 - Create names that REPRESENT these physical locations. I use:
S_LOCAL to represent the path to the config files (C:\local)
S_BIN to represent the path to other scripts and utilities (C:\local\bin).
Define these names on your server as PERMANENT, SYSTEM environment variables. For testing, you can do this manually via My Computer/Properties/Advanced/Environment Variables.

Step 3 - Change your script to reference the config and utility file locations using the names defined above. For example, commands such as
$BlatCmd = 'C:\local\bin\blat.exe'
become
$BlatCmd = '%S_BIN%\blat.exe'

and config file references such as
$Data = ReadProfileString('c:\local\mydata.ini', 'this', 'that')
become
$Data = ReadProfileString('%S_CONFIG%\mydata.ini', 'this', 'that')

Now, when you create scripts, they reference the logical place where config files and utility programs are maintained. So - each time you go to install a new script on a customer's computer, your install script:
  • Prompts you for the location of the S_CONFIG root path, accepting your standard location as a default value
  • Checks for %S_CONIG% - if not defined, it creates S_CONFIG and S_BIN system variables and the folders they represent
  • Copies all the script's files to the appropriate locations

This is precisely what my Customize script does. I create a customize.ini before visiting a client, populate the source folders with the scripts and utilities I want to be able to use while serviceing their systems, and run the script on each server, and any admin workstation where administration tools will be needed. By taking a moment to define the customize.ini for that client (when necessary) I eliminate the prompt for the install directory for this and other utilities. Any install script for add-on utilities - such as my LogCleanup tool - checks for the presence of the S_CONFIG variable and exits if it wasn't defined, complaining that the system was not prepped.

Using this method, I accomplish two things that are important to ME - 1.) I don't have to modify scripts to use them at multiple clients, and 2.) I keep my config files separate from my script folders, making them easier to find.

Keep in mind that this still provides a great deal of flexibility. I have a backup script. The script is in the S_BIN folder, but it has several related configuration files, logs, and more. It references its config files in %S_CONFIG%\Backup\backup.ini, and logs as &S_CONFIG\Backup\Logs\sessionID.log. In fact, most of my scripts write their logs to %S_CONFIG%\logs\... - either directly to that folder, or to a subfolder if they write lots of logs.

The key point of this exercise is to be able to write a script ONCE and use it at HUNDREDS of different client configurations. You can handle the odd situation, too - like having an old server with too little space on C: by moving the C:\Local folder to another drive and simply redefining the two environment vars - no coding changes!

Glenn
_________________________
Actually I am a Rocket Scientist! \:D