Discussion :

[ned57]

Bonjour à tous !
J'aurais besoin de vos lumières concernant un moyen de quitter plusieurs scripts d'un coup.
En effet, j'ai conçu des scripts qui s'appellent les uns les autres, ce qui provoque un hiérarchie à 3 niveaux :
Script père -> Scripts fils -> Scripts "petit-fils"

Le problème est que si une commande s'exécute mal dans un des scripts de niveau 3, un simple exit ferme uniquement ce script là et l'exécution se poursuit au niveau 2.

Est-il du coup possible via un exit (ou une autre commande) de quitter l'ensemble du processus, peu importe le niveau dans lequel on se trouve ?

PS : J'ai testé "set -e" mais cette commande est contraignante car au moindre grep vide, tout s'arrête...

Merci d'avance

[N_BaH]

Bonjour,

exit accepte un argument, qui, si il est supérieur à zéro, indique une erreur.
Peut-il suffire de tester le code de retour d'un script, et de le remonter jusqu'au script père qui lui-même retournera ce code ?

très grossièrement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
./script_père
 
./script_fils
retVal=$?
test $retVal -gt 0 && exit $retVal
#dans script_fils
./script_petit_fils || exit $?

[zipe31]

Salut,

Il te faut sourcer tes scripts (fils et petit-fils) et non les appeler, de ce fait la commande exit arrêtera l'ensemble.

Par contre attention aux variables déclarées, avec le sourçage elle deviennent communes à l'ensemble des scripts...

[ned57]

Merci de vos réponses !
zipe31 : Je viens de tester ta solution avec 2 petits scripts, ça marche nickel. Par contre, ce problème de variables communes est vraiment dérangeant pour moi car ça va me prendre énooooooooooooooormément de temps de tout modifier. J'ai fait l'erreur d'appeler mes variables de manière identique d'un script à l'autre...
N_BaH : Je ne suis pas sûr de comprendre tout à fait ta réponse, mais elle implique également que je source mes scripts j'ai l'impression...

[N_BaH]

elle implique également que je source mes scripts j'ai l'impression...

non.

Code pEre :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
#!/bin/bash
 
./fils || exit $?

Code fils :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
#!/bin/bash
 
./petiFils || exit $?

Code petiFils :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
#!/bin/bash
 
grmblh 2>/dev/null || exit 3

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
./pEre; echo $?
3

donc, erreur!
erreur qui est remontée par les exit depuis le petiFils.

[ned57]

Ah d'accord je vois mieux. Autant pour moi.
Merci beaucoup, je vais voir ce que ça donne

[jack-ft]

PS : J'ai testé "set -e" mais cette commande est contraignante car au moindre grep vide, tout s'arrête...

C'est effectivement très contraignant! Mais bien pratique pour blinder le code!

Il faut à chaque fois tester le code retour (soit avec if until while || &&) ou inverser avec '!' (si le shell le supporte!):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
set -e
! echo coucou | grep coco
if ! echo coucou | grep coco ; then echo 'pas trouvé' ; fi
echo coucou | grep coco || echo 'pas trouvé'
echo coucou | grep coco && echo 'trouvé'
echo coucou | grep coucou && echo 'trouvé'
echo coucou | grep coco || true
echo coucou | grep coco || :
A=$(echo coucou | grep coco) || :
echo "'$A'"

Si le script est un peu long, il vaut mieux s'en être occupé dès le début!

[jack-ft]

Salut,

Il te faut sourcer tes scripts (fils et petit-fils) et non les appeler, de ce fait la commande exit arrêtera l'ensemble.

Par contre attention aux variables déclarées, avec le sourçage elle deviennent communes à l'ensemble des scripts...

Il me semble que le choix de sourcer ou appeler un script devrait être dicté par d'autres considérations que la sortie générale!

Ici, on développe un framework en ksh qui comporte environ 600 fonctions.

Notre choix d'architecture a été de les répartir dans différents modules.
Un script écrit par un de nos clients doit commencer par sourcer notre module chapeau qui source les autres modules (plus ou moins optionnels), ce qui leur permet d'utiliser nos fonctions dans la suite de leur script.
L'alternative aurait été d'écrire des scripts indépendants, mais c'est plus coûteux (chaque appel fait un fork) et, surtout, ça aurait complexifié considérablement le stockage d'informations (certaines de nos fonctions calculent des valeurs qui sont stockées dans des variables globales privées, utilisées ensuite par d'autres fonctions).

Ici, c'est plutôt la rémanence d'informations et la gestion des logs avec log4sh qui a dicté notre choix de sourcer les modules.

[zipe31]

Il me semble que le choix de sourcer ou appeler un script devrait être dicté par d'autres considérations que la sortie générale!.

Je ne faisais que donner une solution parmi d'autres.
Après, les tenants et aboutissants, vu le peu d'information qu'il est donné systématiquement, ne rentrent pas en jeu, d'autant plus que j'ai bien prévenu d'une des incidences possible

Merci quand même d'avoir souligné ce point fort intéressant s'il en est

[ned57]

Après de longues heures à tout remanier, la méthode de N_BaH fonctionne à merveille. C'est là que je me dis qu'il est bon de penser à toutes les problématiques avant de se jeter dans le script...
En tous les cas, merci beaucoup !!!