views:

238

answers:

1

Hi,

I have a couple of scripts for which the first part of them looks the same. Function of this part is to identify at which machine the script is being runned and set a couple of variables accordingly. It looks something like this:

   ENV=`echo $LOGNAME | cut -c1-8`
if  [ $ENV = "vrt3400b" ]
then
   echo "Using TEST specific settings."
   NAME_PREFIX="tst"
   GROUP_NUMBER=`echo $USER | cut -c4-5`
   GROUP_NUMBER_SUFFIX=00`echo $USER | cut -c8-9`
   ...
elif [ $ENV = "vrp3400a" ]
then
   echo "Using PROD specific settings."
   NAME_PREFIX="prd"
   ...

The problem is that as the number of scripts grow the overhead of maintaining small changes gets very time consuming.

I extracted the above part and put it into a separate script, that is then called by all the other scripts. But the variables are fo course not forwarded to the other scripts. Tried export NAME_PREFIX="tst" aswell but it didn't work.

Could anyone give me a hint on which approach I should use to solve the problem?

I was thinking about letting the part identifiying the environment, write properties to file which can then be passed to other scripts. But it seems that there must be a more straightforward approach.

// Mike

+3  A: 

Initializing script (1.sh)

a=123
b=abc

export a b

Application script

#!/bin/sh

. 1.sh

echo \$a: $a
echo \$b: $b
Peter Lindqvist
I was using "#!/bin/sh". But your answer lead me to the conclusion that 'source' can be replaced with '.' if bash is not being used. Great!
Mike
Cool! That works in bash as well it appears. I'll change my answer to reflect that.
Peter Lindqvist
I don't think you necessarily need to export the variables unless you want them to appear in the environments of scripts called as "children" (e.g. of the second script in your example).
Dennis Williamson
Ah yes, you're probably right. I tend to do it just in case.
Peter Lindqvist