Le colon « : » en Bash : l'astuce shell méconnue qui muscle vos scripts

Le 23 juillet 2026, le développeur suédois Filip Roséen publiait sur son blog refp.se un article qui a fait réagir la communauté shell : une astuce vieille de plus de cinquante ans, le colon deux-points de Bash, capable de remplacer plusieurs lignes de script par une seule. Une commande qui, littéralement, ne fait rien, mais qui change beaucoup de choses une fois qu'on sait s'en servir.

On décortique ici ce que fait réellement ce colon, pourquoi il mérite sa place dans vos scripts de production, et comment l'adopter sans rendre votre code illisible pour le reste de l'équipe.

Le colon, ce builtin qui ne fait rien

Pas de panique si vous ne l'avez jamais croisé : : est une commande interne (builtin) présente dans tous les shells compatibles POSIX (Bash, Dash, Zsh, Ksh...). Elle évalue ses arguments puis ignore le résultat, sans jamais échouer. Son origine remonte au tout premier shell Unix, le Thompson shell de 1971, où elle servait déjà d'étiquette et de tout premier marqueur de commentaire sous Unix.

Concrètement, ce builtin renvoie toujours un code de sortie à zéro (succès) et ne produit aucune sortie. Seul, il ne sert donc à rien. Combiné à l'expansion de paramètres de Bash, il devient un outil redoutable de concision et de fiabilité pour vos scripts.

Vérifier un argument obligatoire en une ligne

Le cas d'usage le plus parlant : contrôler qu'un script reçoit bien l'argument dont il a besoin. La version classique, avec un bloc if, ressemble à ceci :

if [ -z "$1" ]; then
    echo "missing argument, aborting!" 1>&2
    exit 1
fi
echo "Hello $1!"

Avec le colon et l'expansion de paramètres, ces quatre lignes tiennent en une seule :

: "${1:?missing argument, aborting!}"
echo "Hello $1!"

La syntaxe ${name:?diagnostic} vérifie si $name est vide ou non défini. Si c'est le cas, le message est envoyé sur la sortie d'erreur et le script s'arrête avec un code de sortie non nul. Sinon, l'expansion renvoie simplement la valeur de la variable, que le colon avale sans broncher, et le script continue normalement.

Des valeurs par défaut sans faute de frappe

Même logique pour fixer une valeur par défaut. La syntaxe habituelle assigne une variable à partir d'elle même avec un opérateur de valeur par défaut. Le problème, relevé par l'auteur dans sa FAQ, c'est que le nom de la variable apparaît deux fois : une fois à gauche de l'assignation et une fois à l'intérieur de l'expansion. Une faute de frappe sur l'un des deux noms crée une variable fantôme et casse silencieusement le script :

# le nom de la variable apparaît deux fois : risque de faute de frappe
DATA_DIR="${DATA_DRI:-/var/data}"

# le colon force à ne l'écrire qu'une seule fois : plus sûr
: "${DATA_DIR:=/var/data}"

En préfixant l'expansion par le colon, le nom de la variable n'apparaît qu'une seule fois. Moins de texte, moins de risque d'erreur de copier coller dans un script de déploiement écrit à la hâte un vendredi soir.

D'autres usages qui valent le détour

Le colon ne se limite pas aux arguments et aux valeurs par défaut. L'auteur en liste plusieurs autres, tout aussi utiles au quotidien :

• Tronquer un fichier de log sans passer par un outil externe, avec : > erreur.log.
• Tester des droits avant de lancer un traitement, en combinant le colon avec une redirection dans un sous-shell, par exemple ( : < fichier.json ) && echo OK.
• Fournir une commande neutre à trap, qui exige toujours une commande, pour rendre un sleep interruptible sans y toucher.
• Écrire une boucle infinie lisible avec un simple while :; do ... done.
• Vérifier plusieurs variables obligatoires d'un coup, associé à l'option set -u, avec quelque chose comme : "$DEPLOY_ENV" "$HOST".

Notre lecture chez CZSyn

Chez CZSyn, une bonne partie de nos scripts tournent sans supervision directe : déploiements, tâches cron sur l'infrastructure de nos clients, sauvegardes automatisées. Dans ce contexte, chaque ligne de script en moins est une ligne de moins qui peut planter à trois heures du matin. L'idiome du colon coche une case rare : il rend le code à la fois plus court et plus robuste, ce qui n'est pas toujours le cas des raccourcis shell.

Notre réserve porte sur la lisibilité. Cette syntaxe n'a rien d'évident pour un développeur qui découvre Bash, et un colon isolé en début de ligne peut ressembler à une faute de frappe aux yeux d'une revue de code pressée. Nous recommandons de la réserver aux scripts d'infrastructure gérés par une équipe familière du shell, et d'ajouter un commentaire la première fois qu'elle apparaît dans un projet. Un dernier point en sa faveur : contrairement à beaucoup d'astuces spécifiques à Bash, celle-ci est définie par POSIX. Elle fonctionne à l'identique sur Dash, Ksh ou le shell par défaut d'une distribution minimaliste, ce qui compte dès que vos scripts doivent tourner sur plusieurs environnements chez différents hébergeurs.

Sources primaires

• Filip Roséen, refp.se, « A shell colon does nothing. Use it anyway. », 23 juillet 2026.
• GNU Bash Reference Manual, « Shell Parameter Expansion ».
• The Open Group, POSIX.1-2017, « Shell Command Language ».