
Envoyé par
AnozerOne
@Sve@r : : J'avais essayé une instruction vide ; mais bash me vomissait une erreur de syntaxe, as tu vraiment essayé cette solution ?
Non désolé, j'ai fait une erreur de souvenir. C'est l'instruction ":" et non ";" (j'ai tapé mon post de mémoire)...
Mais puisqu'on est dans les petites subtilités du shell (je viens de lire http://mywiki.wooledge.org/BashPitfalls que j'ai trouvé pas mal du tout), j'ai remarqué un truc amusant sur les booléens
En effet, dans les langages classiques, un booléen n'est jamais examiné plus que nécessaire. Par exemple dans un if (e1 or e2 or e3), si e1 est vrai, alors l'évaluation ne s'embête pas à examiner e2 et e3 puisque le test est de toute façon vrai. Pareil pour un "et" qui serait faux dès la première expression.
Ce qui est pratique quand l'évaluation de e2 dépend de e1 comme les pointeurs en C
if (pt != NULL && *pt == ...)
Mais pas en shell, comme le démontre le petit code suivant
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
| #!/bin/sh
# Petit script démontrant le comportement d'une évaluation
# Test sur le "ou"
rm -f fichier1
ls -l fichier2
if test -n "$HOME" -o -z "$(>fichier1)"
then
echo "gagné"
ls -l fichier1
fi
# Test sur le "et"
rm -f fichier2
ls -l fichier2
if test -z "$HOME" -a -n "$(>fichier2)"
then
: # Juste pour te faire plaisir :mrgreen:
else
echo "gagné"
ls -l fichier2
fi |
Dans le cas du "ou", comme la variable $HOME n'est pas vide, le "if" est définitivement vrai. Mais au résultat, on se rend compte qu'il a quand-même inutilement évalué l'instruction suivante laquelle va créer le fichier n° 1 (ce qu'on voit lors du "ls")
Et idem dans le cas du "et" où le fichier n° 2 est inutilement créé alors que le "if" est déjà définitivement faux...
Partager