2010-06-29 6 views
1

Je suis en train d'opérer dans un shell Korn, et j'essaie d'exécuter un simple script chdb que j'ai écrit. S'il est exécuté sans arguments, il invite l'utilisateur à fournir une liste de bases de données et attend une sélection. S'il est appelé avec un seul argument numérique, il fera automatiquement la sélection pour l'utilisateur.Le script shell utilise les arguments de la première exécution lorsqu'il est exécuté une seconde fois

Exemple:

> . chdb 
Select the database sid from the following: 
    1) testdb1 
    2) testdb2 
    3) testdb3 

Selection: 2 <-- user entered 

Environment is now set up for testdb2. 
>. chdb 2 
Environment is now set up for testdb2. 
> 

Mon problème est que quand je lance le script avec un argument comme ci-dessus, et puis essayer de l'exécuter à nouveau sans argument, il utilise toujours les vieux arguments.

Exemple:

> . chdb 2 
Environment is now set up for testdb2. 
> . chdb 
Environment is now set up for testdb2. 
> 

EDIT: J'utilise le point parce que je suis en train de variables dans l'environnement et ne veux pas appeler une instance de shell enfant, sinon la configuration de base de données ne fonctionnera pas. J'ai le sentiment que cela peut être la source de mon problème, mais je ne suis pas sûr de savoir comment contourner ce problème.

Une autre chose qui mérite d'être mentionnée est qu'appeler mon script avec au moins 1 argument fonctionnera toujours comme prévu. Il n'utilise jamais d'arguments précédemment entrés sauf s'il est invoqué sans paramètres.

Répondre

0

J'ai trouvé un moyen de gérer cela. J'ai ajouté set -- à la fin de mon script afin qu'il désactive tous les arguments.

Pour toute personne ayant ce même problème, set -- efface tous les arguments ($ 1, $ 2, $ 3 et ainsi de suite). Utilisez shift pour supprimer uniquement le premier ($ 1) ou shift num pour annuler les premiers arguments num. Il s'ensuit que shift $# effacera également tous les arguments.

1

Essayez: après input=$arg, faire un unset arg, ou une citation if [["$#" -ne "1"]]

+0

Bonne suggestion, mais aucune de ces choses a fonctionné pour moi. Cependant, je viens de réaliser que ce problème ne se produit que si j'appelle mon script en utilisant un point en premier (>. Chdb 2). J'avais utilisé un alias, alors j'ai oublié de le mentionner. J'utilise le point car je mets des variables dans l'environnement et je ne veux pas appeler une instance de shell enfant, sinon la configuration de la base de données ne fonctionnera pas. Est-ce que mon problème est un effet secondaire et y a-t-il un moyen de le contourner? – dpatchery

0

également - vous utilisez le code « source » qui signifie toutes les variables de envrionment déclarées dans le script sont toujours là lorsque vous l'exécutez à nouveau.

Essayez

./chdb

au lieu de

. chdb

+0

De la publication, "J'utilise le point parce que je mets des variables dans l'environnement et que je ne veux pas invoquer une instance de shell enfant, sinon la configuration de la base de données ne fonctionnera pas. problème, mais je ne suis pas sûr de savoir comment le contourner. " – dpatchery

1

Si vous utilisez un script avec '.' Pour définir les variables d'environnement, toutes les variables que vous déclarez dans ce script seront automatiquement globales et passeront dans la session du shell appelant.

Il existe trois approches pour isoler vos variables et les rendre non persistants:

1. Initialiser Variables

Si vous utilisez une seule variable pour capturer la sélection de l'utilisateur par exempleDBSELECTION, qu'il soit passé sur la ligne de commande ou entré en mode interactif, alors vous pouvez commencer votre script en initialisant cette variable à une chaîne vide;

DBSELECTION="" 
if [ "$1ZZZ" != "ZZZ" ] ; then 
    DBSELECTION=$1 
else 
    interactiveMode 
fi 

- où "InteractiveMode" est votre processus défini pour obtenir la sélection de l'utilisateur. Vos noms de méthode ou de fonction peuvent varier, bien sûr.

2. Variables serties

Si vous utilisez des variables temporaires pour enregistrer la sélection de l'utilisateur - comme celui ci-dessus, DBSELECTION, vous voudrez peut-déconfigurer la variable à la fin de votre script;

DBSELECTION="" 
if [ "$1ZZZ" != "ZZZ" ] ; then 
    DBSELECTION=$1 
else 
    interactiveMode 
fi 
unset DBSELECTION 

3. Définir locales plutôt que des variables globales

Si vous utilisez des variables temporaires, il peut être plus judicieux de les définir localement (en utilisant typeset) au lieu de le monde, de sorte qu'ils font ne persiste pas au-delà de la fonction dans laquelle ils sont définis. De cette façon, ksh gérera la variable pour vous, plutôt que de la désactiver vous-même.

Questions connexes