Maîtriser les variables simplifie nettement l’écriture de scripts en GNU Bash sur les distributions Linux modernes.
Ce guide pratique décrit les règles de nommage, l’expansion, l’export et les pièges courants pour Ubuntu, Debian et dérivés; il reste utile pour Fedora et Red Hat. Poursuivons par un résumé ciblé pour garder l’essentiel visible facilement.
A retenir :
- Conteneurs en mémoire pour données temporaires de scripts shell
- Variables utilisateur versus variables d’environnement pour comportement applicatif
- Référence via $ ou ${} pour expansion sûre des valeurs
- Exportation nécessaire pour transmission aux processus enfants et sous-shells
À partir du résumé, déclarer et nommer des variables Bash
Cette étape présente la syntaxe simple d’affectation sans espaces autour du signe égal. Par exemple site_name= »OSTechnix » ou this_year=2021 montrent la règle courante du shell.
Dans cette logique, choisir des noms descriptifs pour variables Bash
Privilégier la casse snake_case pour variables utilisateur et MAJUSCULES pour constantes. Éviter les noms réservés et les caractères spéciaux pour réduire les conflits.
Bonnes pratiques de nommage : Ces repères réduisent les conflits et améliorent la lisibilité des scripts shell.
- Utiliser lettres, chiffres et underscore uniquement
- Préférer noms explicites de trois mots maximum
- Réserver MAJUSCULES aux variables d’environnement persistantes
- Éviter noms proches de commandes système
Pour appliquer ces conventions, comprendre l’assignation et le rôle des guillemets
L’affectation s’effectue sans espaces, et la variable est créée à l’instant de l’assignation. L’utilisation de guillemets simples ou doubles change l’expansion et protège des séparateurs.
Élément
Usage
Exemple
Assignation
Attribuer une valeur littérale
site_name= »OSTechnix »
Expansion
Substituer la valeur avec $ ou ${}
echo ${site_name}
Guillemets doubles
Permettent l’expansion des variables
echo « Année ${this_year} »
Guillemets simples
Bloquent toute expansion
msg=’$(date) non exécuté’
Substitution commande
Stocker sortie d’une commande
today_date=$(date)
« J’ai réduit les erreurs d’expansion en systématisant ${} dans mes scripts de déploiement. »
Alice R.
Selon Rocky Documentation Team, la substitution de commande via $() est la forme recommandée pour la clarté. Selon Chet Ramey, la variable existe dès son assignation et persiste jusqu’à la fin du script.
Après avoir fixé la syntaxe, il faut aborder l’accès, la réaffectation et la portée des variables. Le point suivant détaille l’accès direct, l’export et la portée pour les processus enfants.
Suite au travail sur la syntaxe, accéder et manipuler les variables en Bash
Accéder à une variable se fait avec $variable ou ${variable} pour délimiter le nom. La différenciation évite les collisions lors d’assemblage de chaînes et de suffixes.
Dans ce passage, la réaffectation et declare expliquées pour Bash
La réaffectation est triviale en Bash, car les variables sont typées faiblement. On peut réaffecter une chaîne puis une valeur numérique sans déclaration préalable.
Techniques d’affectation : La commande declare permet d’ajouter des attributs comme -i ou -r selon le besoin.
- Réassigner directement pour modifier la valeur
- declare -i pour conversions arithmétiques automatiques
- declare -r ou readonly pour verrouiller la variable
- unset pour supprimer valeur et attributs
Dans la continuité, exporter et persister les variables vers l’environnement
L’export rend une variable visible par les processus enfants mais pas l’inverse. Pour persister une variable entre sessions, il faut la placer dans ~/.bashrc ou ~/.bash_profile selon l’usage.
Commande
Effet
Usage typique
export VAR
Transmet la variable aux enfants
export PATH
declare -i
Force l’interprétation arithmétique
declare -i count=3
declare -r / readonly
Verrouille la variable en lecture seule
readonly VERSION
unset
Supprime la variable
unset temp_var
echo ${#var}
Renvoie la longueur d’une chaîne
echo ${#site_name}
Selon Rocky Documentation Team, l’usage de readonly protège des réaffectations accidentelles en production. Selon Chet Ramey, export reste la méthode standard pour les variables d’environnement.
Un administrateur témoigne de gains de robustesse en automatisant l’export de variables critiques. Ce changement a amélioré la reproductibilité des tâches sur CentOS et Kali Linux.
« Après avoir exporté mes variables critiques, mes scripts systemd ont arrêté d’échouer en production. »
Marc L.
Après avoir maîtrisé l’export et declare, il reste à connaître les variables spéciales et les bonnes pratiques pour la maintenance. La section suivante couvre ces sujets et propose conseils pour sécuriser les scripts.
Enfin, exploiter variables spéciales, export et bonnes pratiques pour production
Les variables spéciales comme $? et $$ apportent des informations utiles pour le diagnostic. Leur compréhension accélère le débogage et permet de rendre les scripts plus résilients.
Dans ce dernier volet, utiliser les variables spéciales pour contrôle et journalisation
$? indique le code de sortie de la dernière commande, utile pour vérifier le succès d’une opération. $$ renvoie l’identifiant du processus, pratique pour générer des noms de fichiers temporaires uniques.
- Vérifier codes de sortie avec $? après commandes critiques
- Utiliser $$ pour suffixer fichiers temporaires et éviter collisions
- Récupérer arguments de script avec $1 à $9 pour flexibilité
- Compter arguments avec $# pour validations simples
Selon Debian-facile, l’utilisation correcte de $@ et $* évite les surprises lors du traitement d’arguments. Ces variables sont indispensables pour écrire des scripts portables sur openSUSE et Arch Linux.
Pour conclure ce chapitre, verrouiller et documenter les variables en production
Verrouiller les constantes avec readonly et consigner les variables critiques dans la documentation du projet. Placer les exports persistants dans ~/.bashrc ou /etc/profile selon la portée visée.
- Documenter variables d’environnement dans README d’exploitation
- Utiliser readonly pour constantes ne devant pas changer
- Mettre exports persistants dans ~/.bashrc pour sessions utilisateurs
- Tester scripts sur Debian, Ubuntu et Fedora avant déploiement
« J’ai ajouté readonly aux constantes et évité des remplacements accidentels en production. »
Simon P.
Un avis d’expert souligne que la lisibilité prime pour la maintenance à long terme des scripts shell. La pratique systématique de conventions réduit les erreurs sur Red Hat et les variantes commerciales.
« Adopter des conventions claires m’a fait gagner des heures en revue de code. »
Claire V.
Source : Chet Ramey, « Bash Reference Manual », GNU ; Rocky Documentation Team, « Bash – Using Variables », Rocky Linux Documentation, March 2022 ; Debian-facile, « Script bash : variables, arguments, paramètres », Debian-facile.