Le crochet '[' sous Linux est-il une vraie commande

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 ]

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).

Vérification de la valeur de retour après condition vraie

À 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 ]

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).

Lecture du code de retour signalant une condition fausse

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 :

Création de l’arborescence temporaire de test

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.

Contrôle de présence d’un fichier standard avec le paramètre -f

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.

Validation de la structure de dossier avec l’indicateur -d

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.

Détection d’un fichier de taille nulle à l’aide de l’option -s

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 :

Écriture de données dans le fichier d’essai

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.

Mise en œuvre du crochet d’évaluation dans une structure if then

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 :

Suppression complète des données de 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.