Maîtriser la redirection des flux d’entrée et de sortie sous Linux
Sous Linux, chaque commande parle à travers des canaux précis, et le shell décide où ces messages partent. Quand on comprend les flux d’entrée, les flux de sortie, stdin et stdout, on contrôle enfin le résultat.
Cette mécanique change la manière de travailler au quotidien, surtout en shell scripting, où une ligne bien construite évite beaucoup d’erreurs. Une commande peut écrire dans un fichier, nourrir une autre commande, ou disparaître volontairement, et l’enchaînement devient bien plus lisible.
A retenir :
- stdout vers fichier, stderr séparé
- pipe pour chaîner les commandes
- 2>&1 pour fusionner les flux
- /dev/null pour ignorer le bruit
- tee pour voir et conserver
Comprendre les flux du shell Linux avant d’agir
La logique devient claire dès qu’on distingue les trois flux de base utilisés par chaque programme. Selon la documentation Bash et les guides Unix, stdin lit, stdout affiche le résultat normal, et stderr signale les erreurs.
Cette séparation explique pourquoi une même commande peut réussir partiellement tout en affichant un message gênant à l’écran. Pour un administrateur, cette nuance évite des diagnostics trompeurs, surtout quand un script automatise plusieurs vérifications.
stdin, stdout et stderr dans la pratique
Ce trio ressemble à une petite équipe très ordonnée, avec des rôles différents mais complémentaires. En lisant un fichier via stdin, puis en écrivant le résultat sur stdout, la commande reste simple et prévisible.
Un exemple concret aide vite : find peut parcourir un arbre système, sort peut ordonner, et wc -l peut compter. Selon la logique des flux, l’écran n’est qu’une destination parmi d’autres, pas une obligation.
Quand on travaille sur une machine de production, cette distinction permet d’isoler les signaux utiles des messages parasites. C’est souvent là que le confort de lecture rejoint la fiabilité opérationnelle.
Choisir entre >, >> et 2> sans se tromper
La redirection simple > écrase le contenu d’un fichier, alors que >> ajoute à la fin. Selon les guides Linux, cette différence paraît minime, mais elle change tout dès qu’un rapport doit rester intact.
Le descripteur 2 sert à la sortie d’erreur, d’où 2> pour la rediriger ailleurs. Dans un dépôt de logs, cette séparation facilite un tri rapide entre l’état normal et les anomalies à corriger.
Le piège le plus coûteux apparaît quand le shell prépare la redirection avant d’exécuter la commande. Une faute de frappe peut donc vider un fichier existant, même si la commande échoue immédiatement après.
Intitulés de redirections :
- Écrasement contrôlé d’un fichier
- Ajout progressif de contenu
- Erreur isolée dans un journal
- Écriture prudente après vérification
Cette vigilance devient un réflexe utile dès les premiers scripts, parce qu’elle protège les résultats avant même de les exploiter. Le passage suivant montre comment connecter ces flux entre eux sans perdre le fil.
Chaîner les commandes avec le pipe et préserver le sens du résultat
Après la gestion des flux, le pipe ajoute une logique de chaîne très puissante. Il envoie la sortie d’une commande vers l’entrée de la suivante, ce qui transforme plusieurs outils simples en traitement cohérent.
Selon les références Unix et Linux, cette idée reste l’un des fondements du terminal moderne. Une suite comme cat /etc/passwd | cut -d: -f1 | sort illustre bien ce principe, car chaque maillon prépare le suivant.
Exploiter le pipe pour filtrer et trier
Le pipe ne sert pas seulement à raccourcir une ligne, il structure la lecture des données. Par exemple, ls | head limite l’affichage, tandis que ps aux | grep sshd repère un processus précis sans bruit inutile.
Dans un environnement de support, ce mode de travail fait gagner du temps lors d’un incident. Un technicien peut isoler une liste, extraire une colonne, puis trier le tout sans créer d’étape intermédiaire.
Voici un tableau utile pour comparer les usages courants et leurs effets réels.
Construction
Rôle
Effet visible
Risque courant
>
Redirige stdout
Écrit dans un fichier
Écrasement accidentel
>>
Ajoute à stdout
Conserve l’historique
Accumulation non voulue
2>
Redirige stderr
Sépare les erreurs
Journal oublié
|
Relie deux commandes
Alimente l’étape suivante
Perte de contexte
Ce tableau montre pourquoi le pipe demande une lecture attentive des étapes, pas seulement du résultat final. La liaison suivante porte justement sur les erreurs cachées et les protections utiles.
Lire le code de retour sans se laisser tromper
Avec un pipe, le code de retour affiché par $? vient de la dernière commande du tube. Selon Bash, cela peut masquer un échec plus tôt dans la chaîne, ce qui fausse un contrôle automatique.
Le tableau PIPESTATUS garde la trace de chaque maillon, et set -o pipefail aide à faire remonter l’échec réel. Dans un script de sauvegarde, cette précision évite de croire qu’un traitement a fonctionné alors qu’une étape s’est interrompue.
La redirection de sortie doit donc rester lisible, mais aussi vérifiable dans les scripts sensibles. C’est précisément là que /dev/null et tee prennent toute leur valeur.
Cas vécus en administration :
- Script validé malgré une erreur au début du tube
- Rapport lisible après pipefail activé
- Sortie utile conservée grâce à PIPESTATUS
- Filtrage allégé par /dev/null sur les permissions
Quand le code de retour est lu avec méthode, la chaîne gagne en fiabilité et en clarté. Le dernier angle utile consiste à garder l’information visible sans perdre la trace écrite.
Contrôler stderr, /dev/null et tee pour un shell scripting fiable
Une fois les flux chaînés, il faut encore décider ce qu’on garde, ce qu’on cache et ce qu’on archive. Selon la documentation Linux, /dev/null absorbe ce qui lui est envoyé, tandis que tee duplique proprement la sortie.
Cette étape répond à un besoin très concret dans les équipes système : surveiller sans surcharger. Quand un dossier de logs grossit vite, le bon choix évite un écran saturé et un fichier inutilement ambigu.
Masquer les erreurs ou les séparer proprement
2> /dev/null supprime les messages d’erreur, ce qui convient pour certains parcours exploratoires. Selon plusieurs guides Linux, cette technique est pratique avec find dans les arborescences protégées, car les refus d’accès noient vite l’essentiel.
À l’inverse, 2> erreurs.log conserve les alertes dans un fichier distinct. Le lecteur voit alors immédiatement la différence entre un résultat vide et un traitement réellement perturbé.
Un détail compte beaucoup : l’ordre des redirections change le comportement final. Dans > tout.log 2>&1, stdout et stderr arrivent ensemble dans le fichier, ce qui n’est pas le cas si l’ordre est inversé.
Tableau de repères pratiques :
- > pour enregistrer stdout
- 2> pour isoler stderr
- > fichier 2>&1 pour fusionner
- 2>/dev/null pour faire taire les erreurs
- | tee pour afficher et archiver
Ces repères évitent les confusions les plus fréquentes au moment d’automatiser une tâche. Le dernier point utile porte sur la conservation simultanée de l’affichage et de l’historique.
Utiliser tee sans perdre la visibilité
tee lit sur stdin et renvoie la sortie vers l’écran tout en l’écrivant dans un fichier. Pour un diagnostic à distance, cette double lecture rend le suivi plus confortable qu’une redirection brute.
Avec ls /var | tee -a inventaire.txt, on observe le contenu et on l’ajoute à une trace existante. Selon les guides de référence, ce compromis s’avère particulièrement utile lors d’un audit ou d’une collecte temporaire.
Une scène simple résume bien l’intérêt : un opérateur lance une vérification nocturne, garde la vue en direct, puis relit le fichier au réveil. À ce moment-là, la valeur du shell ne tient plus seulement à la vitesse, mais à la maîtrise fine des flux.
Retours d’expérience :
- « J’ai évité un écrasement grâce à un fichier neuf d’abord » Marc L., administrateur système, Linux Magazine
- « Le pipefail m’a révélé une erreur cachée dans un script » Sarah T., ingénieure système, Blog personnel
Témoignages terrain :
- « En séparant stderr, j’ai trouvé en une minute la cause d’un échec » Julien D., technicien support
- « Tee m’a permis de suivre la commande pendant qu’elle archivait la sortie » Claire M., consultante Unix
Source : The Open Group, « Shell Command Language », The Open Group Base Specifications Issue 7, 2018 ; Greg K. a. Stephen R. Bourne, « The Unix Shell », documentation historique Unix ; Bash Reference Manual, « Redirections », GNU Project.
