Linux pour les devs - 13 - Les variables d'environnement : configurer sans hardcoder

export, PATH, .bashrc, .profile et fichiers .env : comprendre les variables d'environnement Linux en profondeur.

  1. 01 Linux pour les devs - 00 - Pourquoi Linux meme si tu codes sur Mac ou Windows
  2. 02 Linux pour les devs - 01 - Le terminal, bash et zsh
  3. 03 Linux pour les devs - 02 - Fichiers et répertoires
  4. 04 Linux pour les devs - 03 - Permissions et droits d'acces
  5. 05 Linux pour les devs - 04 - Utilisateurs, groupes et sudo
  6. 06 Linux pour les devs - 05 - nano, vim, sed et awk
  7. 07 Linux pour les devs - 06 - Pipes et redirections
  8. 08 Linux pour les devs - 07 - grep et find en profondeur
  9. 09 Linux pour les devs - 08 - Les processus : comprendre ce qui tourne sur ta machine
  10. 10 Linux pour les devs - 09 - systemd : gerer tes services comme un pro
  11. 11 Linux pour les devs - 10 - Le réseau : comprendre ce qui passe par le fil
  12. 12 Linux pour les devs - 11 - Le firewall : contrôler qui entre et qui sort
  13. 13 Linux pour les devs - 12 - SSH : l'acces distant sécurisé
  14. 14 Linux pour les devs - 13 - Les variables d'environnement : configurer sans hardcoder
  15. 15 Linux pour les devs - 14 - Scripts bash : automatiser pour ne plus se répéter
  16. 16 Linux pour les devs - 15 - cron : les taches planifiees
  17. 17 Linux pour les devs - 16 - Les logs : lire, filtrer, comprendre
  18. 18 Linux pour les devs - 17 - Stockage et disques
  19. 19 Linux pour les devs - 18 - Les gestionnaires de paquets
  20. 20 Linux pour les devs - 19 - Les conteneurs sans Docker
  21. 21 Linux pour les devs - 20 - Securiser un serveur Linux
  22. 22 Linux pour les devs - 21 - Performance et diagnostic
  23. 23 Linux pour les devs - 22 - tmux : le multiplexeur de terminal
  24. 24 Linux pour les devs - 23 - Glossaire Linux

13 - Les variables d'environnement : configurer sans hardcoder

Ce que tu vas apprendre

  • Ce que sont les variables d'environnement et comment elles fonctionnent
  • Manipuler le PATH et comprendre son rôle
  • La différence entre .bashrc, .profile et .bash_profile
  • Rendre des variables persistantes
  • Le rapport entre les fichiers .env et Linux

Prerequisites

Savoir utiliser SSH et le terminal. Avoir bash comme shell (c'est le défaut sur la plupart des distributions).


La première fois que j'ai du ajouter quelque chose au PATH, j'ai copie une commande de Stack Overflow sans comprendre ce que je faisais. Ca a marche. Puis j'ai ouvert un nouveau terminal et ca ne marchait plus. Ce genre de frustration disparaît quand tu comprends comment les variables d'environnement fonctionnent.

C'est quoi une variable d'environnement

Une variable d'environnement, c'est une paire clé/valeur disponible pour tous les processus d'une session. Quand tu lances un programme, il hérité des variables de son parent. C'est le mecanisme standard pour passer de la configuration a une application sans la mettre dans le code.

bash# Voir toutes les variables d'environnement
env

# Ou
printenv

# Voir une variable precise
echo $HOME
printenv HOME

# Definir une variable (visible uniquement dans le shell courant)
MA_VAR="bonjour"
echo $MA_VAR

# Exporter : la rend visible aux processus enfants
export MA_VAR="bonjour"

# Definir et exporter en une ligne
export DB_HOST="localhost"

# Supprimer une variable
unset MA_VAR

La différence entre MA_VAR="valeur" et export MA_VAR="valeur" est subtile mais fondamentale. Sans export, la variable existe dans le shell courant mais n'est pas transmise aux processus que tu lances. Avec export, elle est héritée.

bash# Sans export
SECRET="abc"
node -e "console.log(process.env.SECRET)"
# undefined

# Avec export
export SECRET="abc"
node -e "console.log(process.env.SECRET)"
# abc

# Variable ponctuelle pour une seule commande
DB_HOST=localhost DB_PORT=5432 node server.js

Le PATH : comment Linux trouve tes commandes

Quand tu tapes node, le shell ne cherche pas partout sur le disque. Il regarde dans les répertoires listes dans la variable PATH, dans l'ordre :

bashecho $PATH
# /usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin

# Chaque repertoire est separe par ':'
# Le shell cherche 'node' dans /usr/local/bin, puis /usr/bin, etc.

# Savoir ou se trouve un binaire
which node
# /usr/local/bin/node

# Ajouter un repertoire au PATH (pour la session courante)
export PATH="$HOME/.local/bin:$PATH"

# Le mettre au debut signifie qu'il sera cherche en priorite

Un piège classique : tu installes un outil avec npm install -g ou cargo install, mais la commande n'est pas trouvee. C'est presque toujours un problème de PATH. Le répertoire d'installation n'est pas dans ton PATH.

bash# Bun installe dans ~/.bun/bin
export PATH="$HOME/.bun/bin:$PATH"

# Cargo installe dans ~/.cargo/bin
export PATH="$HOME/.cargo/bin:$PATH"

# Go installe dans ~/go/bin
export PATH="$HOME/go/bin:$PATH"

.bashrc vs .profile vs .bash_profile

C'est la que ca se complique, et ou la plupart des gens se perdent. Chaque fichier est lu a un moment différent :

.profile (ou .bash_profile) est lu une seule fois, au login. C'est l'endroit pour les variables d'environnement qui doivent etre disponibles partout (PATH, EDITOR, LANG). Sur les systèmes modernes avec un bureau graphique, il est lu au démarrage de la session.

.bashrc est lu a chaque ouverture d'un terminal interactif non-login. C'est l'endroit pour les alias, les fonctions, le prompt, et la configuration spécifique au shell.

bash# ~/.profile - variables globales
export EDITOR="vim"
export PATH="$HOME/.local/bin:$PATH"

# ~/.bashrc - configuration du shell
alias ll="ls -la"
alias gs="git status"

# Prompt personnalise
PS1="\u@\h:\w$ "

En pratique, sur Ubuntu, .bashrc est source depuis .profile. Donc mettre tes exports dans .bashrc marche aussi. Mais si tu veux etre propre :

  • Variables d'environnement dans .profile
  • Alias et config shell dans .bashrc

Sourcer un fichier

Quand tu modifies .bashrc, les changements ne s'appliquent pas au terminal deja ouvert. Tu dois "sourcer" le fichier :

bash# Deux syntaxes equivalentes
source ~/.bashrc
. ~/.bashrc

source exécuté le fichier dans le shell courant (pas dans un sous-process). C'est pour ca que les variables définies dedans deviennent disponibles.

Variables persistantes vs session

Pour résumer clairement :

bash# Variable de session (disparait quand tu fermes le terminal)
export API_KEY="abc123"

# Variable persistante (ajoute dans un fichier de config)
echo 'export API_KEY="abc123"' >> ~/.bashrc
source ~/.bashrc

Sur un serveur, pour une application, je préféré mettre les variables dans le fichier unit systemd :

ini# Dans /etc/systemd/system/mon-app.service
[Service]
Environment=NODE_ENV=production
Environment=PORT=3000
EnvironmentFile=/opt/mon-app/.env

Les fichiers .env : une convention, pas une feature Linux

Les fichiers .env ne sont pas natifs a Linux. Ton shell ne les lit pas automatiquement. C'est une convention popularisee par des outils comme dotenv (Node), python-dotenv, et Docker Compose.

bash# .env
DB_HOST=localhost
DB_PORT=5432
DB_NAME=monapp

# Linux ne charge PAS ce fichier automatiquement
# Mais tu peux le sourcer manuellement (si les lignes ont 'export')

# Methode manuelle
set -a  # marque automatiquement toutes les variables comme exportees
source .env
set +a

# Docker Compose le lit nativement
docker compose up  # lit .env par defaut

Sur paltemps.fr, j'utilise un fichier .env charge par l'application Bun directement (Bun supporte .env nativement). Le système Linux ne le voit jamais.

Résumé

  • export rend une variable visible aux processus enfants
  • Le PATH est une liste de répertoires ou le shell cherche les commandes
  • .profile pour les variables, .bashrc pour la config du shell
  • source fichier pour appliquer des changements sans ouvrir un nouveau terminal
  • Les fichiers .env sont une convention applicative, pas une feature du système

Article précédent : SSH Article suivant : Les scripts bash

Sources

Réservez un audit gratuit de 30 minutes. Je vous montre concrètement ce qu'on peut automatiser.