Shell Programming and Scripting

I've searched Google and now this forum. Best guess is my search fu is not good (and it probably isn't). The Google search did bring me here.

Background
I have a number of Korn Shell scripts who all use one of 3 values for an environment variable used in the backup system.
On occasion one or more value will be changed by the backup team.

This make me have to manually edit each script to change the value.


What I'd like to do is have 3 files. Each containing one value.

And have the value brought into the script and exported as the value for the specific environment variable.

Thanks
WolfBrother

???

Why not give the requested value as an argument of your script?
(will avoid the editing phase...)

Good question - the script generally is a self contained script that may have to be executed by someone who may not know the valid value for that specific application.

I am an Oracle DBA. The specific scripts I'm dealing with are for one specific system. The backup parm is a sched id. For that one specific system there are three values. Other systems I have range from one completely different sched id to 5 differing sched ids. All specific to the system/DB instance they're backing up. Somewhere around 50 different ones just for the DBs I'm primary on. We're a fairly large organization, we have 15+ DBA's so you get an idea as to just the number of sched ids we'd have to remember.

I try to write my scripts so that all you have to do is execute the script without having to know the specifics to that system.

We source an instance specific <SID>.env file for specific environment variables. I could set them there but would still multiple edits if a sched id changes again.

Putting those environment variables common to several scripts known to have a history of being changed (like the sched ids for our backups) in a file that multiple scripts get the value from cuts down the number of edits made (and consequently the number of possible mistakes I could make).

Our scripting guru decided that Oregon was a better place to go so I'm having to learn more now.

Thanks.
Wolf Brother

You could display the wanted values by testing if no arguments are given (would have to test the one given is valid anyway...)

if you source the file it will work
e.g
var.file

Code:

VAR=blah

Code:

. var.file
etc
etc
echo $VAR

What shell do you use (ksh, bash, sh ... whatever) ?
What are the names and example values of the three environment variables?

The sourcing using dot-space-scriptname advised above is the correct method.

Korn Shell. 1 environment variable - 3 possible values at this time.

File names and value's
1mo - XFG1moDR
2mo - XFG2mo
3mo - XFG3mo.

The environment variable in one of the korn shell scripts needing one of the three values depending on the backup requirements:
NB_ORA_SCHED.

I'm wanting to read/source/bring in the value of one the 3 files.
As in
whatever it takes to get 1mo value into a variable in the shell and then:
export NB_ORA_SCHED=<shell variable>

I have 17 Oracle instances on a very large server,
each instance with it's own backup script.

9 uses the value in 3mo, 6 uses the value in 2mo, and 2 uses the value in 1mo as the value for the environment variable NB_ORA_SCHED.

Over the past few years - as the process changes - these values have changed. SO rather than manually editing 17 scripts to change the value, I'm wanting to edit 1 of 3 files as needed.

Again, these scripts are parameterized to some degree within the script. However, they are written so that if my backup, my backup's backup, my backup's backup's backup, and I get hit with a bus, any DBA can be given access to the server and will be able to manually (if needed) submit the backup without having to know anything other than
1. log on to server
2. go to this place
3. manually submit this .ksh script.

The plan is to make it as simple as it should be but no simpler.

As a note. Above, when I mentioned the process, you need to understand the way its done here. We have any number of pointy headed managers who feel the need to do something managerish fairly frequently. One way to do that is to rename items. So what one month may be bk_onsite_1mo may become XFG1mo the next.

You must understand - the process is paramount. Resistance is futile, you will be assimilated.

Being able to put values that change into a file that get read into a ksh script is one way to cut down on the impact of such managerish actions.

The scripting guru was not assimilated, he managed to go somewhere else. Me, I get to learn more about Korn shell scripting now.

Thanks again.
WolfBrother