Utilisées sans toujours comprendre leur fonctionnement, les redirections dans les shells Unix représentent pourtant des outils fondamentaux pour quiconque manipule un terminal. Ces commandes, qu’on trouve dans bash, zsh ou autres environnements Unix, contrôlent les flux d’entrée et de sortie, façonnant ainsi le comportement des scripts ou des commandes ponctuelles. Sans une maîtrise minimale, copier-coller des exemples trouvés sur StackOverflow peut vite laisser perplexe sur ce qui s’opère réellement sous le capot. Plongeons dans ces redirections fréquentes, afin d’y voir plus clair dans leur mécanique et leurs enjeux. Cela permettra d’éviter des erreurs fatales, comme l’effacement accidentel de logs ou la perte des messages d’erreur indispensables au diagnostic.
Les systèmes Unix reposent largement sur trois canaux de communication standard, la base même des redirections : stdin (entrée standard, numéro 0), stdout (sortie standard, numéro 1) et stderr (erreur standard, numéro 2). Quand on tape une commande dans un terminal, ces trois flux déterminent ce qui est lu, affiché ou capturé. Comprendre ces fondations simplifie l’usage des redirections, souvent perçues comme des symboles mystérieux voire effrayants. Voici 5 redirections incontournables qu’il faut vraiment saisir pour exploiter pleinement le potentiel du shell Unix dans la gestion des entrées/sorties.
- 🔄 Redirection de la sortie standard vers un fichier (> et >>)
- 🚫 Redirection des erreurs vers un fichier ou suppression (2>, 2>> et 2>/dev/null)
- 🔗 Fusion des sorties standard et erreur (2>&1 et &>)
- 📥 Gestion avancée des entrées avec redirection d’entrée (<)
- 🕳️ Suppression silencieuse de toute sortie vers /dev/null
Comprendre la redirection de sortie standard : > et >> dans un script Unix
Le symbole > est sans doute le plus couramment utilisé pour rediriger la sortie standard d’une commande vers un fichier. Par exemple, taper echo "Bonjour le monde" > message.txt écrit la chaîne dans le fichier message.txt. Si ce fichier existe déjà, son contenu est aussitôt écrasé, perdant toute donnée précédente. Cette particularité expose à un risque fréquent quand on travaille avec des logs ou des fichiers importants.
Pour sécuriser ces opérations, il est possible de configurer l’environnement shell avec set -o noclobber dans le fichier .bashrc, ce qui bloque l’écrasement fortuit. Dans ce cas, il faudra forcer l’écrasement via |>. Cette protection évite bien des désagréments, surtout lorsque des scripts tournent automatiquement et manipulent des fichiers critiques.
Quand l’objectif est d’ajouter du contenu à la fin d’un fichier sans effacer l’existant, la variante >> entre en jeu. Par exemple, echo "Nouvelle ligne" >> historique.log ajoute la nouvelle ligne à la suite du fichier. C’est le choix recommandé pour tracer des logs continus ou enregistrer des sorties successives sans perte d’information.
Cette différence subtile entre > et >> fait toute la différence : on peut passer de situations où des heures de travail disparaissent sans avertissement à une gestion robuste des flux d’information.
Redirections des erreurs standard : 2> et 2>> pour le nettoyage et le suivi des incidents
Le flux d’erreur standard (stderr) est identifié par le numéro 2. Par défaut, toutes les erreurs apparaissent à l’écran, ce qui peut vite devenir bruyant et difficile à suivre, surtout dans les scripts automatisés. Pour rediriger ces erreurs vers un fichier, on utilise 2>. Par exemple, commande_qui_peut_échouer 2> erreurs.log place toute erreur dans fichier erreurs.log, qui pourra ensuite être analysé à froid.
Comme pour la sortie standard, il est possible d’accumuler les erreurs en utilisant 2>> afin d’ajouter les messages sans écraser ce qui existe, ce qui est utile pour les traitements planifiés à intervalle régulier. Un bon exemple est la surveillance d’un serveur via un script cron où garder un historique complet des erreurs est nécessaire.
Pour rendre ces redirections robustes, il faut ne pas mettre d’espace entre le 2 et le >, sinon Bash peut confondre ce 2 avec un argument. L’attention portée à ce détail révèle combien la compréhension même élémentaire des file descriptors est précieuse pour éviter les erreurs d’écriture dans le terminal.
Fusionner les sorties standard et erreur : 2>&1 et &>, un secret bien compris
Un grand classique, parfois mal compris, est la fusion des deux flux de sortie. Soit on veut capter à la fois la sortie standard et les erreurs dans un seul fichier, soit les envoyer dans le même canal pour contrôle.
Cette opération s’effectue en deux étapes : d’abord, on redirige stdout vers un fichier avec >, puis on demande à stderr (flux 2) de pointer vers la même destination que stdout avec 2>&1. Par exemple :
commande > sortie.log 2>&1
Ce qui signifie « redirige la sortie normale vers sortie.log et fais en sorte que le flux d’erreurs suive la sortie normale ». Attention, l’ordre des redirections est important : inverser pourrait entraîner la perte des erreurs dans le terminal.
D’ailleurs, depuis l’arrivée des shells récents comme bash ou zsh, une syntaxe plus concise est disponible : >&. Ce raccourci est pratique mais perd un peu en portabilité suivant votre environnement.
Ces outils sont souvent utilisés pour des scripts complexes où il est nécessaire d’obtenir un log unique, clair et ordonné. Un bon entrepreneur digital saura que maîtriser ces subtilités évite notamment d’ignorer des erreurs dans des pipelines automatisés.
La gestion des entrées standard avec la redirection < et pourquoi ça fait la différence dans un script
Si la sortie standard est souvent mise en avant, l’entrée standard (stdin, numéro 0) reste un levier sous-estimé. La redirection d’entrée via < permet de faire lire un fichier ou une source à une commande comme si elle venait du clavier.
Par exemple, avec une commande comme commande < fichier.txt, la commande récupère son entrée du fichier fichier.txt plutôt que de l’utilisateur. Cette capacité est indispensable pour certains traitements automatiques où la saisie interactive n’est pas possible.
Au-delà des scripts, cela facilite les automatismes dans des environnements Unix multi-utilisateurs ou lors de tests de commandes avec des données d’entrée prédéfinies. Elle est aussi essentielle dans des commandes « filtre » ou « parseur » qui traitent du texte en mode batch.
En exploitant cette redirection, on peut aussi enchaîner plusieurs commandes en cascade, s’appuyant sur des fichiers intermédiaires ou des pipelines, plus efficaces que des saisies manuelles.
Redirections vers /dev/null : maîtriser le silence dans le terminal
Dans un environnement Unix, /dev/null est surnommé « le trou noir » ou le « puit sans fond ». Tout ce qui y est envoyé disparaît instantanément. Utiliser 2>/dev/null permet donc de supprimer les messages d’erreur : la commande find / -name "*.conf" 2>/dev/null évite d’afficher les centaines de messages « Permission denied » souvent générés lors de telles recherches. Cela rend la sortie bien plus lisible et focalisée sur les résultats utiles.
On peut pousser l’usage jusqu’à supprimer toute sortie standard et erreur avec >/dev/null 2>&1 ou son raccourci &>/dev/null. Cette technique est précieuse dans les scripts de maintenance sous crontab où aucun retour n’est souhaité, évitant d’encombrer la boîte mail ou la console d’alertes.
Mais attention à ne pas abuser de cet outil en production, car masquer toutes les sorties peut cacher des erreurs importantes qu’il faudrait corriger. Comme souvent, la maîtrise et le discernement guident la bonne utilisation de ces redirections.
- 🔍 Utilisez /dev/null pour supprimer les sorties indésirables
- ⚠️ Évitez de cacher systématiquement toutes les erreurs pour garder un suivi
- 🔧 Combinez /dev/null avec d’autres redirections pour plus de flexibilité
