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é
exportrend une variable visible aux processus enfants- Le PATH est une liste de répertoires ou le shell cherche les commandes
.profilepour les variables,.bashrcpour la config du shellsource fichierpour appliquer des changements sans ouvrir un nouveau terminal- Les fichiers
.envsont une convention applicative, pas une feature du système
Article précédent : SSH Article suivant : Les scripts bash