#187359 - 2008-04-27 10:42 AM
Re: A script that will update variables in another script
[Re: Richard H.]
|
ddady
Getting the hang of it
Registered: 2006-09-03
Posts: 98
|
Yes, it does.
So i guess that Richard's suggestion is the way form me. Just to put the 2 scripts and the INI file in one folder and that's it!?
If you keep your CONFIG script, PROCESS script and INI file in the same folder you can make things a little more simple and use the built-in macro @SCRIPTDIR to determine the location: CLS
'Send mail to: ' Gets $MailUser ?
' Mail Server: ' Gets $MailServer ?
$ = WriteProfileString(@SCRIPTDIR+'\checkdisk.ini', 'COMMON', 'MailUser', $MailUser)
$ = WriteProfileString(@SCRIPTDIR+'\checkdisk.ini', 'COMMON', 'MailServer', $MailServer) @SCRIPTDIR is populated automatically with the path to the directory that the script is run from, so saves you the effort of setting an environment variable.
|
|
Top
|
|
|
|
|
#187360 - 2008-04-27 02:20 PM
Re: A script that will update variables in another script
[Re: ddady]
|
Glenn Barnas
KiX Supporter
Registered: 2003-01-28
Posts: 4396
Loc: New Jersey
|
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! 
|
|
Top
|
|
|
|
|
#187362 - 2008-04-27 06:36 PM
Re: A script that will update variables in another script
[Re: Sealeopard]
|
Glenn Barnas
KiX Supporter
Registered: 2003-01-28
Posts: 4396
Loc: New Jersey
|
Yeah, if every one of your clients used AD, or Exchange... and - in my current environment, the Exchange server won't accept mail from anything but the defined mail relay/spam filter server, which isn't in AD.
The key to this concept is flexibility - not adjusting or adapting your scripts (plural!) to each customer environment, but rather adjusting one set of parameters shared by al scripts. Could be an INI file, but again - where? How do the ALL scripts locate it? @SCRIPTDIR is one way, but not one I prefer. I guess it comes from my *ix background, where config files were generally centralized, and not maintained in the same folder as the commands that used them..
I can walk into any client environment, run my customize script (with any appropriate tweaks) and then install/run any other script in my library without any scripting change. That's an important and powerful capability when you're supporting dozens of different client networks.
Glenn
_________________________
Actually I am a Rocket Scientist!
|
|
Top
|
|
|
|
|
#187363 - 2008-04-27 10:32 PM
Re: A script that will update variables in another script
[Re: Glenn Barnas]
|
ddady
Getting the hang of it
Registered: 2006-09-03
Posts: 98
|
Thanks Glenn, that's what i needed, your explanation was very detailed. Step 2 was what i've been missing or better say didn't understand.
Will try it tomorrow on the company server.
BTW, why doing it manually from My Computer/Properties/Advanced/Environment Variables is only for testing? Isn't suppose to be permanent?
Edited by ddady (2008-04-27 10:33 PM)
|
|
Top
|
|
|
|
Moderator: Jochen, Allen, Radimus, Glenn Barnas, ShaneEP, Ruud van Velsen, Arend_, Mart
|
1 registered
(Allen)
and 566 anonymous users online.
|
|
|
