Introduction
Dans l’environnement de terminal Ubuntu, la plupart des administrateurs considèrent le symbole ouvrant [ comme un simple élément de ponctuation syntaxique au sein des blocs conditionnels. En réalité, ce caractère correspond à un véritable exécutable autonome doté d’une logique propre. Ce guide décortique les arcanes de la commande [, son comportement d’évaluation et l’exploitation systématique du statut de sortie $? dans vos automatisations.
1. Découverte du binaire ‘[’ et analyse de sa résolution par le shell
Pour attester que ce crochet existe physiquement sur le disque comme n’importe quel utilitaire système, interrogeons les chemins de recherche standards via which [ :
L’interpréteur renvoie immédiatement /usr/bin/[. Ce résultat confirme qu’il ne s’agit pas d’une simple construction de langage, mais bien d’un fichier exécutable classique.
⚙️ [Options fondamentales d’évaluation]
-f : Vérifie si la cible constitue un fichier standard (regular file).-d : Détermine si l’emplacement ciblé est un répertoire.-e : Valide l’existence effective de la ressource (fichier ou dossier).-z : Renvoie vrai si la chaîne de caractères transmise est vide (longueur nulle).-n : Confirme que la chaîne de caractères possède au moins un caractère.= : Évalue la stricte égalité textuelle entre deux chaînes.-eq : Compare deux entiers et vérifie leur équivalence numérique.-ne : Constate une divergence de valeur entre deux entiers.
![Localisation de la commande avec which
L’exploration de la hiérarchie d’exécution se poursuit grâce à la commande type -a [, qui détaille la manière dont Bash résout cet appel :
On observe que le shell priorise une version interne (shell builtin) pour maximiser les performances d’exécution, tout en conservant les fichiers binaires compilés sous /usr/bin/[ et /bin/[ pour garantir la conformité POSIX standard.
![Résolution de la commande via type -a
Pour inspecter la nature exacte du fichier physique présent dans l’arborescence, exécutons ls -l /usr/bin/[ :
Les attributs de sécurité affichent les permissions standard -rwxr-xr-x, certifiant son statut de programme binaire exécutable par l’ensemble des utilisateurs du système.
![Attributs et permissions du fichier binaire /usr/bin/
2. Principes fondamentaux de manipulation et lecture du code d’état ($?)
Effectuons un premier test de comparaison logique avec la commande [ 10 -gt 5 ] afin de vérifier si 10 est strictement supérieur à 5 (-gt pour greater than) :
L’outil n’émet aucun message sur la sortie standard (stdout) lors du calcul : l’ensemble du verdict transite exclusivement par son code de terminaison.
![Évaluation de supériorité numérique avec [ 10 -gt 5 ]](/ubuntu/20261010_020600_29/captures/s02_c01_10_-gt_5.png)
La variable spéciale $? permet de récupérer instantanément ce verdict d’évaluation via echo $? :
La valeur 0 s’affiche sur la console. Dans la convention UNIX, ce zéro symbolise une terminaison sans erreur, soit une condition logique strictement vraie (True).

À l’inverse, tentons de vérifier si 10 est inférieur à 5 au moyen de l’expression [ 10 -lt 5 ] (-lt signifiant less than) :
Comme attendu, le terminal reste muet, le système mémorisant l’échec de la comparaison directement dans le registre du processus.
![Test de comparaison inférieure avec [ 10 -lt 5 ]](/ubuntu/20261010_020600_29/captures/s02_c03_10_-lt_5.png)
L’interrogation de l’état du processus via echo $? met en évidence la réponse négative du système :
Un code différent de zéro (généralement 1) est renvoyé, indiquant sans ambiguïté que le test s’est soldé par un état faux (False).

3. Pratique des validations de système de fichiers (-f, -d, -s)
Pour expérimenter ces prédicats en conditions réelles, créons un environnement de test isolé comprenant un dossier et un fichier vierge via mkdir -p /tmp/bracket_test && touch /tmp/bracket_test/sample.txt :

Validons la présence de notre fichier ordinaire au moyen de la syntaxe [ -f /tmp/bracket_test/sample.txt ] && echo "파일이 정상적으로 존재합니다" :
L’expression étant validée avec succès, l’opérateur logique && déclenche la commande d’affichage consécutive.

Pour nous assurer que la structure parente est bien reconnue comme un dossier, exécutons [ -d /tmp/bracket_test ] && echo "디렉터리가 맞습니다" :
L’analyse confirme le type de l’objet inspecté et émet immédiatement le message confirmant la nature du répertoire.

Testons maintenant la présence de données utiles au sein du fichier via [ -s /tmp/bracket_test/sample.txt ] || echo "파일 크기가 0(비어있음)입니다" :
Notre cible ayant une taille nulle, le critère -s échoue. Le connecteur logique de repli || intercepte ce statut et affiche l’alerte signalant un fichier vide.

4. Intégration avancée dans les structures conditionnelles Bash
Injectons du texte dans notre fichier de démonstration à l’aide de l’instruction echo "Ubuntu Shell Test" > /tmp/bracket_test/sample.txt pour simuler un cas réel de traitement de données :

Imbriquons à présent ce contrôle dans une structure conditionnelle complète grâce à if [ -s /tmp/bracket_test/sample.txt ]; then echo "내용 확인: $(cat /tmp/bracket_test/sample.txt)"; fi :
La vérification de non-vacuité (-s) retournant un code de succès, le sous-bloc then prend le relais, affichant le contenu extrait du fichier sans accroc.

Enfin, finalisons notre session d’apprentissage en nettoyant les artefacts temporaires générés sur la machine à l’aide de rm -rf /tmp/bracket_test :

Vous disposez désormais d’une vision limpide de la nature profonde de [ dans les écosystèmes Linux, de sa double existence binaire/builtin, ainsi que du rôle pivot des codes d’erreur $?. Maîtriser cette mécanique interne vous évitera nombre de pièges de syntaxe et renforcera la robustesse de vos scripts shell d’automatisation.