bon , grâce au cours de l’IUT Rodez j’ai compris ce qu’il se passe et surtout comment fonctionne un « tube » : rien ne vaut un schéma clair qui m’a fait comprendre où se situait mon erreur .
la sortie est effectivement correcte mais comments’appelle cette commande || , que je ne pense pas avoir rencontrée ?
manuel bash:
commande_1 && commande_2 commande_2 est exécutée si, et seulement si, commande_1 renvoie zéro comme état final (succès). Une liste OU a la forme commande_1 || commande_2 commande_2 est exécutée si, et seulement si, commande_1 renvoie un état final différent de zéro. L'état renvoyé par des listes ET et OU est l'état final de la dernière commande exécutée dans la liste.
À noter que c’est illogique, en C || = «ou», && = «et», pour évaluer
rm quelquechose 2> /tmp/glop || cat /tmp/glop
on peut s’attendre à ce que bash commence par évaluer rm quelquechose 2> /tmp/glop et, en cas de succès donc de retour de code 0, n’évalue pas le second.Pour &&, en cas d’échec, il évaluerait le second… Or bash fait l’inverse…
$ rm glup && echo pouet
rm: impossible de supprimer ‹ glup ›: Aucun fichier ou dossier de ce type
$ rm glup || echo pouet
rm: impossible de supprimer ‹ glup ›: Aucun fichier ou dossier de ce type
pouet
$
En fait il raisonne comme si code de retour =0 —> succès —> valeur VRAI (donc VRAI || xxx = VRAI, évaluation paresseuse, on n’évalue pas xxx), de même code de retour >0 ----> erreur —> FAUX (donc FAUX && xxx = xxx qu’il faut évaluer)
C’est pareil en shell. Dans les deux cas la seconde expression n’est évaluée que si c’est nécessaire compte tenu du résultat de la première. La seule différence, ce sont les valeurs numériques considérées comme « vrai » ou « faux » qui sont inversées en C et en shell (0 = « vrai/succès » en shell et « faux/échec » en C) mais c’est généralement transparent lorsque les valeurs sont des codes de retour ou des conditions.
Non, en cas d’échec donc code != 0. En cas de succès de la première commande il n’y a pas lieu d’exécuter la seconde.
Dans un OU, il suffit qu’un des opérandes soit vrai pour que le résultat soit vrai donc si le premier opérande est vrai on n’a pas besoin d’évaluer l’autre pour connaître le résultat.
Ben oui, cet inversion 0 = Ok, >0 = souci rend cohérent || = ou et && = et mais va à l’encontre de C. Pour être cohérent avec C il aurait fallu inverser || et && dans bash. Mais bon, une fois qu’on sait que VRAI=0 en bash, c’est correct…
Ces choix sont arbitraires dans les deux cas.
Le choix d’une logique positive par le C est intuitif et compréhensible car le langage est assez bas niveau.
Le choix d’une logique inversée par le shell s’impose à partir du moment ou on décide que le code de retour d’une commande vaut 0 en cas de succès et une autre valeur en cas d’échec (ce qui permet d’indiquer la cause de l’échec avec des valeurs différentes).
J’allais dire que c’est surtout celui des processeurs (JNE, JE) mais JE = égalité du résultat à zéro mais aussi branchement si comparaison vraie (il simule une soustraction, donc égalité = 0), hum… C’est arbitraire, c’est vrai finalement