Comment inspecter les variables d’environnement Linux sans exposer un secret ?

Un script fonctionne dans votre terminal, puis échoue une fois lancé par cron, systemd ou un autre compte. La différence vient souvent de son environnement : PATH, proxy, locale, répertoire courant ou variable applicative ne sont pas forcément les mêmes. Avant de modifier une configuration, commencez par regarder ce que le processus reçoit vraiment.

Le piège est simple : env peut aussi afficher un jeton d’API, un mot de passe ou une URL contenant des identifiants. Ne copiez jamais une sortie complète dans un ticket public, un dépôt Git ou un message de chat.

Tux inspecte des variables d’environnement Linux devant un coffre protégé — Inspectez les variables utiles, sans transformer un diagnostic en fuite de secret.

Lire une variable précise avant d’afficher tout le reste

printenv et env affichent les variables exportées par le shell. Pour un diagnostic, ciblez d’abord la variable qui vous intéresse :

printenv PATH
printenv LANG
printenv http_proxy

Si la variable n’existe pas, printenv NOM ne produit rien et renvoie un code différent de zéro. C’est utile dans un script de contrôle. Dans un shell interactif, printf '%sn' "$PATH" reste pratique, mais il lit une variable du shell, y compris si elle n’est pas exportée.

Vous pouvez afficher une liste plus large avec env ou printenv, puis filtrer sans dévoiler les valeurs :

printenv | cut -d= -f1 | sort
printenv | grep -Ei '^(PATH|LANG|TZ|http_proxy|https_proxy)='

La première commande ne garde que les noms. Elle permet de confirmer la présence d’une variable sans imprimer un éventuel secret. Pour une sortie déjà enregistrée, retirez au minimum les lignes contenant TOKEN, KEY, SECRET ou PASSWORD, mais considérez ce filtrage comme une aide de lecture, pas comme une garantie de sécurité.

Tester une variable pour une seule commande

Il n’est pas nécessaire de modifier votre profil Bash pour vérifier une hypothèse. Placez la variable devant la commande : elle ne s’applique qu’à ce processus et à ses enfants.

LANG=C date
TZ=UTC date
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin command -v rsync

Cette forme évite de laisser une modification active dans votre session. Elle est particulièrement utile pour reproduire un souci de locale ou de PATH réduit. Gardez toutefois les chemins système nécessaires : un PATH bricolé peut faire lancer une mauvaise version d’une commande, ou empêcher le script de trouver logger, curl ou ssh.

Comparer votre terminal avec cron ou systemd

Cron démarre avec un environnement minimal. Dans une crontab, utilisez des chemins absolus et définissez explicitement les variables dont le script dépend. Pour capturer les noms de variables sans leurs valeurs, ajoutez temporairement ceci dans un script de test :

env | cut -d= -f1 | sort > /tmp/mon-script.env-names
command -v python3 >> /tmp/mon-script.env-names

Avec systemd, inspectez l’unité avant de chercher dans votre fichier ~/.bashrc. Les directives Environment=, EnvironmentFile= et un PATH défini dans le service changent le contexte. Après une modification d’unité, relancez systemctl daemon-reload, puis vérifiez le journal du service.

Vous pouvez aussi comparer avec une commande lancée comme l’utilisateur du service. Le résultat est plus parlant qu’une sortie récupérée depuis votre compte administrateur :

sudo -u www-data env | cut -d= -f1 | sort
sudo -u www-data command -v php

Adaptez www-data à l’utilisateur réel du service. Ne lancez pas cette commande sur un compte applicatif si vous n’avez pas à en consulter l’environnement.

Ne transmettez pas un secret par env

Une variable d’environnement est pratique pour transmettre une configuration à un processus, mais elle peut apparaître dans des journaux, des dumps de diagnostic, des interfaces de supervision ou des commandes copiées trop vite. Pour une clé durable, préférez un fichier de configuration aux permissions strictes, un coffre à secrets ou le mécanisme prévu par votre outil.

Si vous devez montrer un diagnostic, transmettez les noms des variables, leur présence et le chemin résolu de la commande. Gardez la valeur pour vous. Pour compléter ce contrôle, relisez aussi notre guide sur la commande export sous Linux et celui sur l’historique Bash et les secrets. Vous éviterez de corriger un problème d’environnement en laissant une clé dans votre historique.