Il y a deux cas où je trouve :
utile:
Affectations de variables par défaut
#!/bin/sh
# set VAR to "default value" if not already set in the environment
: "${VAR=default value}"
# print the value of the VAR variable. Note that POSIX says the behavior
# of echo is implementation defined if the first argument is '-n' or if any
# argument contains a '\', so use printf instead of echo.
printf '%s\n' "VAR=${VAR}"
Il s'agit d'un moyen pratique pour permettre aux utilisateurs de votre script shell de remplacer un paramètre sans modifier le script. (Cependant, les arguments de ligne de commande sont meilleurs car vous ne courez pas le risque d'un comportement inattendu si l'utilisateur possède par hasard la variable que vous utilisez dans son environnement exporté.) Voici comment l'utilisateur remplacerait le paramètre:
VAR="other value" ./script
La ${VAR=value}
syntaxe dit ensemble VAR
à value
si VAR
ce n'est déjà, puis développez à la valeur de la variable. Comme nous ne nous soucions pas encore de la valeur de la variable, elle est passée en argument à la commande no-op :
pour la jeter.
Même s'il :
s'agit d'une commande no-op, l'expansion est effectuée par le shell (pas la :
commande!) Avant d'exécuter la :
commande afin que l'affectation des variables se produise toujours (le cas échéant).
Il serait également acceptable d'utiliser true
ou une autre commande à la place :
, mais le code devient plus difficile à lire car l'intention est moins claire.
Le script suivant fonctionnerait également:
#!/bin/sh
# print the value of the VAR variable. Note that POSIX says the behavior
# of echo is implementation defined if the first argument is '-n' or if any
# argument contains a '\', so use printf instead of echo.
printf '%s\n' "VAR=${VAR=default value}"
Mais ce qui précède est beaucoup plus difficile à maintenir. Si une ligne utilisant ${VAR}
est ajoutée au-dessus de cette printf
ligne, l'extension d'affectation par défaut doit être déplacée. Si le développeur oublie de déplacer cette affectation, un bogue est introduit.
Quelque chose à mettre dans un bloc conditionnel vide
Les blocs conditionnels vides doivent généralement être évités, mais ils sont parfois utiles:
if some_condition; then
# todo: implement this block of code; for now do nothing.
# the colon below is a no-op to prevent syntax errors
:
fi
Certaines personnes soutiennent que le fait d'avoir un vrai if
bloc vide peut rendre le code plus facile à lire que la négation du test. Par exemple:
if [ -f foo ] && bar || baz; then
:
else
do_something_here
fi
est sans doute plus facile à lire que:
if ! [ -f foo ] || ! bar && ! baz; then
do_something_here
fi
Cependant, je pense qu'il existe quelques approches alternatives qui sont meilleures qu'un vrai bloc vide:
Mettez la condition dans une fonction:
exotic_condition() { [ -f foo ] && bar || baz; }
if ! exotic_condition; then
do_something_here
fi
Mettez la condition entre accolades (ou entre parenthèses, mais les parenthèses génèrent un processus de sous-shell et toutes les modifications apportées à l'environnement à l'intérieur du sous-shell ne seront pas visibles en dehors du sous-shell) avant de nier:
if ! { [ -f foo ] && bar || baz; } then
do_something_here
fi
Utilisez ||
au lieu de if
:
[ -f foo ] && bar || baz || {
do_something_here
}
Je préfère cette approche lorsque la réaction est une simple ligne, telle que l'affirmation de conditions:
log() { printf '%s\n' "$*"; }
error() { log "ERROR: $*" >&2; }
fatal() { error "$@"; exit 1; }
[ -f foo ] && bar || baz || fatal "condition not met"