2009-11-11 20 views
2

J'ai plusieurs scripts dont la première partie est identique. La fonction de cette partie est d'identifier à quelle machine le script est exécuté et de définir quelques variables en conséquence. Il ressemble à ceci:Exportation de variables d'un script shell vers un autre

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" 
    ... 

Le problème est que le nombre de scripts poussent les frais généraux du maintien de petits changements se prend beaucoup de temps.

J'ai extrait la partie ci-dessus et l'ai placée dans un script séparé, qui est ensuite appelé par tous les autres scripts. Mais les variables ne sont pas transmises aux autres scripts. Essayé export NAME_PREFIX="tst" mais cela n'a pas fonctionné.

Quelqu'un pourrait-il me donner une indication sur l'approche que je devrais utiliser pour résoudre le problème?

Je pensais à laisser la partie identifier l'environnement, écrire des propriétés dans un fichier qui peut ensuite être passé à d'autres scripts. Mais il semble qu'il doit y avoir une approche plus directe.

// Mike

+0

qui shell utilisez-vous? –

Répondre

6

scénario Initialiser (1.sh)

a=123 
b=abc 

export a b 

script d'application

#!/bin/sh 

. 1.sh 

echo \$a: $a 
echo \$b: $b 
+1

J'utilisais "#!/Bin/sh". Mais votre réponse m'amène à la conclusion que «source» peut être remplacé par «. si bash n'est pas utilisé. Génial! – Mike

+0

Cool! Cela fonctionne dans bash aussi bien qu'il semble. Je vais changer ma réponse pour refléter cela. –

+2

Je ne pense pas que vous ayez nécessairement besoin d'exporter les variables sauf si vous voulez qu'elles apparaissent dans les environnements de scripts appelés "enfants" (par exemple du deuxième script dans votre exemple). –