Redirections et pipes sous Linux

Sous Linux, chaque commande produit du texte en sortie, et ce texte peut être envoyé ailleurs que l'écran. Vers un fichier, vers une autre commande, ou même vers le néant (/dev/null). Ce mécanisme s'appelle la redirection et c'est l'un des concepts les plus puissants du shell. Combiné avec le pipe (|), il permet d'enchaîner des commandes simples pour accomplir des tâches complexes.

Ce que vous allez apprendre

• Rediriger la sortie d'une commande vers un fichier avec > et >>
• Distinguer sortie standard et sortie d'erreur
• Enchaîner des commandes avec le pipe |
• Masquer les erreurs avec /dev/null
• Afficher et enregistrer en même temps avec tee
• Éviter les quatre pièges qui font perdre des données ou mentent sur le résultat

Les trois flux du shell

Avant de rediriger quoi que ce soit, il faut comprendre que chaque commande utilise trois flux :

Flux	Numéro	Nom	Rôle
Entrée standard	0	stdin	Ce que la commande lit (clavier par défaut)
Sortie standard	1	stdout	Le résultat normal (écran par défaut)
Sortie d'erreur	2	stderr	Les messages d'erreur (écran par défaut)

Glissez pour voir

Par défaut, stdout et stderr arrivent toutes les deux à l'écran. Les redirections permettent de les envoyer ailleurs.

Rediriger la sortie vers un fichier

Un processus écrit par défaut sur deux flux distincts, la sortie standard et la sortie d'erreur. La redirection détourne le premier vers un fichier ; le second continue de s'afficher à l'écran tant qu'on ne le traite pas séparément.

>, écrire (en écrasant)

L'opérateur > envoie la sortie standard dans un fichier. Si le fichier existe, il est écrasé :

ls /etc > liste.txt

Le fichier liste.txt contient maintenant la liste des fichiers de /etc. Rien ne s'affiche à l'écran.

Vérifiez :

head -n 5 liste.txt

>>, ajouter à la fin

L'opérateur >> ajoute à la fin du fichier sans écraser le contenu existant :

echo "--- Fin du rapport ---" >> liste.txt

Attention à >

> écrase le fichier sans avertissement. Si vous voulez conserver le contenu existant, utilisez toujours >>.

> vide le fichier même quand la commande échoue

Voici le piège qui coûte le plus cher aux débutants, et il n'est pas évident : c'est le shell qui prépare la redirection, avant de lancer la commande. Le fichier est donc vidé en premier, quoi qu'il arrive ensuite.

echo "des données importantes" > rapport.txt
commande-qui-nexiste-pas > rapport.txt

bash: commande-qui-nexiste-pas: command not found

La commande n'a jamais tourné, elle sort en erreur (code 127), et pourtant :

stat -c %s rapport.txt

0

Le fichier fait zéro octet. Une simple faute de frappe dans un nom de commande suffit donc à effacer un fichier existant. Le réflexe qui protège est d'écrire d'abord dans un fichier neuf, puis de remplacer l'ancien une fois le résultat vérifié.

Créer un fichier à partir de rien

Rediriger echo est un moyen simple de créer un petit fichier :

echo "nameserver 1.1.1.1" > /tmp/resolv-test.conf

Rediriger les erreurs

Chaque flux porte un descripteur numérique : 1 pour la sortie standard, 2 pour les erreurs. C'est ce numéro qu'on place devant le chevron pour choisir le flux à détourner, > seul étant un raccourci pour 1>.

2>, rediriger stderr

Pour envoyer les messages d'erreur dans un fichier séparé :

find /etc -name "*.conf" 2> erreurs.log

Les résultats normaux s'affichent à l'écran. Les erreurs « Permission denied » vont dans erreurs.log.

2>/dev/null, ignorer les erreurs

/dev/null est un fichier spécial qui avale tout ce qu'on lui envoie. C'est le « trou noir » de Linux :

find / -name "sshd_config" 2>/dev/null

Les erreurs « Permission denied » disparaissent, seuls les résultats utiles s'affichent.

Rediriger stdout et stderr ensemble

Pour envoyer tout (résultat + erreurs) dans un même fichier :

find / -name "*.log" > tout.log 2>&1

2>&1 signifie « envoie le flux 2 (stderr) là où va le flux 1 (stdout) ».

L'ordre compte, et il n'est pas intuitif. Le shell lit les redirections de gauche à droite. Dans > tout.log 2>&1, stdout part d'abord dans le fichier, puis stderr est envoyé « au même endroit que stdout », donc dans le fichier aussi. Inversez, et vous n'obtenez plus la même chose :

commande 2>&1 > tout.log

Ici, stderr est envoyé « là où va stdout » alors que stdout pointe encore vers l'écran. Il part donc à l'écran, et seul stdout finit dans le fichier. Mesuré sur une commande produisant 16 octets sur stdout et 59 sur stderr :

Écriture	Contenu du fichier
> tout.log 2>&1	75 octets, les deux flux
2>&1 > tout.log	16 octets, stdout seul

Glissez pour voir

Retenez la forme correcte : la redirection de stdout vient en premier.

N'écrivez jamais `> f 2> f`

La tentation est grande de rediriger les deux flux vers le même fichier en les nommant deux fois. Cela détruit une partie de la sortie. Les deux redirections ouvrent le fichier séparément, chacune avec son propre curseur positionné à zéro : le second flux écrit par-dessus le premier.

Sur la même commande à 16 + 59 octets, > f 2> f ne laisse que 59 octets, la sortie standard ayant été recouverte. La forme > f 2>&1 en donne bien 75. Un seul fichier, une seule ouverture : c'est tout l'intérêt de 2>&1.

Le pipe |, enchaîner des commandes

Le pipe (|) connecte la sortie d'une commande à l'entrée de la suivante. C'est la base de la philosophie Unix : des outils simples combinés entre eux.

Exemple de base

ls /etc | head -n 5

ls liste les fichiers, le pipe envoie cette liste à head qui n'affiche que les 5 premières lignes.

Enchaîner plusieurs pipes

cat /etc/passwd | cut -d: -f1 | sort

1. cat /etc/passwd, affiche le fichier
2. cut -d: -f1, extrait le premier champ (le nom d'utilisateur) en utilisant : comme séparateur
3. sort, trie par ordre alphabétique

Le résultat : la liste triée de tous les utilisateurs du système.

Compter des résultats

ls /etc | wc -l

wc -l compte le nombre de lignes. Ici, le nombre de fichiers et répertoires dans /etc.

Filtrer avec grep

ps aux | grep "sshd"

ps aux liste tous les processus, grep ne garde que ceux contenant « sshd ».

Un tube réussi peut cacher une commande ratée

Dès que vous mettrez un pipe dans un script, ce détail vous rattrapera : le code de retour d'un tube est celui de sa dernière commande, pas celui de la première qui a échoué.

commande-absente | wc -l
echo $?

0

commande-absente n'existe pas, mais wc -l a compté zéro ligne sans se plaindre, et c'est son code qui ressort. Un script qui teste $? conclut que tout s'est bien passé.

Bash garde pourtant la trace de chaque maillon dans le tableau PIPESTATUS :

commande-absente | wc -l
echo "${PIPESTATUS[@]}"

127 0

Le 127 est bien là. Dans un script, le plus simple est de demander au shell de propager l'échec avec set -o pipefail, qui fait alors ressortir 127.

tee, afficher et enregistrer en même temps

Par défaut, une redirection > envoie tout dans le fichier et rien à l'écran. Si vous voulez les deux :

ls /etc | tee liste.txt

Le résultat s'affiche à l'écran et est enregistré dans liste.txt.

Pour ajouter au fichier au lieu d'écraser :

ls /var | tee -a liste.txt

Cas d'usage typique de tee

tee est très utile quand vous surveillez un script long et voulez garder une trace :

./mon-script.sh | tee journal.log

Récapitulatif

Opérateur	Rôle	Exemple
>	Redirige stdout vers un fichier (écrase)	ls > fichier.txt
>>	Redirige stdout vers un fichier (ajoute)	echo "fin" >> fichier.txt
2>	Redirige stderr vers un fichier	find / -name x 2> err.log
2>/dev/null	Ignore les erreurs	find / -name x 2>/dev/null
> f 2>&1	Redirige stdout + stderr	cmd > tout.log 2>&1
|	Pipe : sortie d'une commande → entrée de la suivante	ls | head
tee	Affiche et enregistre en même temps	ls | tee fichier.txt

Glissez pour voir

Dépannage

Problème	Cause probable	Solution
> a écrasé mon fichier	> écrase toujours	Utiliser >> pour ajouter
Mon fichier est vide alors que la commande a échoué	> vide le fichier avant d'exécuter la commande	Écrire dans un fichier neuf, puis remplacer une fois le résultat vérifié
Le pipe ne donne rien	La première commande ne produit pas de sortie	Tester la première commande seule
Le tube « réussit » alors qu'une commande a échoué	Le code de retour est celui de la dernière commande	Lire ${PIPESTATUS[@]}, ou set -o pipefail dans un script
Une partie de la sortie manque dans le fichier	Écriture en > f 2> f : deux ouvertures, deux curseurs	Utiliser > f 2>&1
Permission denied avec >	Pas le droit d'écrire dans le répertoire	Voir l'encadré ci-dessous : sudo seul ne suffit pas
Les erreurs polluent le résultat	stdout et stderr mélangés à l'écran	Ajouter 2>/dev/null
tee : commande introuvable	Très rare, paquet coreutils manquant	sudo dnf install coreutils (RHEL/AlmaLinux) ou sudo apt install coreutils (Debian/Ubuntu)

Glissez pour voir

`sudo commande > /fichier-protégé` ne marche pas

C'est le contresens le plus fréquent sur les redirections. Mettre sudo devant la commande ne donne aucun droit à la redirection : le > est traité par votre shell, qui tourne toujours sous votre compte, et c'est lui qui se heurte au refus.

sudo echo "test" > /etc/demo.conf

bash: /etc/demo.conf: Permission denied

Le message tombe avant même que sudo soit lancé. Deux formes fonctionnent, au choix :

echo "test" | sudo tee /etc/demo.conf > /dev/null

sudo sh -c 'echo "test" > /etc/demo.conf'

Dans la première, c'est tee qui écrit, et lui tourne bien sous sudo. Dans la seconde, c'est un shell lancé par sudo qui interprète le >.

Mettre en pratique

La différence entre > et 2> ne devient un réflexe qu'une fois qu'on a produit soi-même les fichiers attendus. Ce lab vous demande de séparer stdout et stderr, de les fusionner quand c'est utile, puis d'enchaîner des commandes au pipe pour fabriquer des artefacts exacts, contrôlés à l'octet près.

Lab pratique

Rediriger les flux et chaîner les commandes avec les pipes

$ dsoxlab run l1-redirections-pipes

Environnement : Shell·Durée : ~20 min

Validé : la sortie produite est comparée au résultat attendu.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI dsoxlab, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
git clone https://github.com/stephrobert/linux-dsoxlab-training.git
cd linux-dsoxlab-training

Lancer ce lab, puis valider votre travail :

dsoxlab run l1-redirections-pipes
dsoxlab check l1-redirections-pipes

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• > écrase, >> ajoute, c'est la différence la plus importante.
• > vide le fichier avant d'exécuter la commande : une faute de frappe suffit à effacer un fichier existant.
• | (pipe) est le ciment de la ligne de commande : il connecte les outils entre eux.
• Le code de retour d'un tube est celui de la dernière commande : ${PIPESTATUS[@]} ou set -o pipefail pour voir les autres.
• 2>/dev/null supprime les erreurs, indispensable avec find lancé sans sudo.
• Pour fusionner les flux, > f 2>&1 et jamais > f 2> f, qui en détruit une partie. L'ordre compte.
• sudo cmd > /fichier échoue toujours : la redirection est faite par votre shell. Utilisez | sudo tee.
• tee est le compromis : afficher à l'écran et garder une trace dans un fichier.

×

📖 Voir la documentation →