Stdin, stdout, kezaco ?

Durée: 12m25s

Date de sortie: 25/11/2025

L'entrée et la sortie standard sont des canaux de communications entre les différents programmes, mais à quoi servent-ils exactement ?

Salut et bienvenue dans ce nouvel épisode du podcast de Code Garage.
Je m'appelle Nicolas Bernard Bernard et aujourd'hui,
on va aborder un concept qui est très simple
et pourtant confond ou en tout cas qu'on n'arrive pas toujours bien à expliquer.
Et ce concept, c'est l'entrée et la sortie standard.
Alors quand on commence à s'intéresser à la programmation,
en fait, on tombe assez vite sur ces deux notions-là qui sont au début un peu mystérieuses.
Alors on parle d'entrée et de sortie standard,
parfois on parle de STD in et STD out,
STD étant l'acronyme pour standard et IN et OUT pour entrer et sortir, comme vous l'aurez compris.
Et en réalité, pour définir très simplement ces deux concepts,
eh bien ce sont des canaux de communication entre un programme et le monde extérieur.
Alors on va commencer par le plus simple, c'est la sortie standard.
Ok ? Quand un programme va effectuer des actions, des calculs, peu importe,
il va parfois avoir envie de partager ses résultats avec le monde extérieur.
Quand vous lancez par exemple un script depuis un terminal,
un script, ça reste un logiciel,
eh bien tout ce qu'il va retourner dans sa sortie standard de base,
eh bien, donc ça peut être des textes, des messages, des résultats, peu importe,
il va l'envoyer dans sa sortie standard
et le terminal lui va récupérer cette sortie standard et l'afficher directement à l'écran.
L'exemple le plus simple, c'est quand vous utilisez la commande ECO sur Linux par exemple
et que vous mettez un message après, eh bien ce logiciel, cette commande, qu'est-ce qu'elle fait ?
Elle dit simplement, prend ce que l'utiliteur envoie en paramètres, c'est une string,
et envoie là dans la sortie standard, c'est tout ce que ça fait.
Et donc, eh bien on se retrouve avec le même message par exemple Hello World
que vous avez mis dans ECO, eh bien il va apparaître directement en dessous.
Alors c'est là que parfois vient la confusion la plus courante
et on va se dire la sortie standard c'est tout simplement l'écran.
Non pas du tout, la sortie standard ça reste juste un canal de communication
et là en l'occurrence c'est notre petit programme ECO qui va rentrer en communication
avec le terminal qu'il a lancé.
Le terminal va récupérer la sortie standard de la commande qu'il vient d'effectuer
et va en faire ce qu'il veut.
En règle générale, le terminal il va afficher la sortie.
Mais ce qui est intéressant c'est que cette sortie standard
elle peut être redirigée ailleurs par exemple, l'exemple le plus courant c'est dans un fichier.
Donc si on fait notre ECO Hello World par exemple,
et qu'au lieu d'exécuter simplement ça,
mais à la suite de notre commande on va mettre un chevron qui pointe vers la droite
et on va mettre je sais pas log.txt par exemple,
et bien cette fois ci rien ne s'affiche dans le terminal
puisque le texte a été envoyé dans la sortie standard
et la sortie standard grâce au chevron a été redirigée vers un fichier
au lieu que ce soit au terminal de le prendre et de la fichier à l'écran.
C'est un des piliers de la philosophie UNIX,
c'est châner et rediriger des programmes
un petit peu comme vous pourrez faire avec des blocs de l'égo ou des choses comme ça.
Et ça marche grosso modo à peu près paris sous Windows
avec des syntaxes différentes et des nuances,
mais voilà on va garder la même philosophie.
Donc maintenant qu'on a compris que la sortie standard
c'est un canal de communication depuis le logiciel
qui est en train de tourner vers l'extérieur,
et bien on va pouvoir parler de l'entrée standard,
et c'était IN,
et bien qui est simplement le canal opposé
et c'est un canal par lequel un programme va pouvoir recevoir des données.
Alors par défaut,
cet entrée standard,
quand vous lancez un logiciel depuis votre terminal,
et bien ce qui va être directement redirigé vers l'entrée standard de votre logiciel,
c'est le clavier.
Donc quand vous lancez un logiciel par exemple
et qu'il attend des informations,
il va attendre des informations dans son entrée standard,
et donc quand vous allez taper au clavier,
ça va être envoyé directement dans le logiciel
et une fois que vous allez taper sur entrée,
c'est là qu'on va faire un flush
et qu'on va tout envoyer d'un coup pour que ce soit pris en compte,
et tout ça passe par l'entrée standard.
Mais il faut bien se mettre en tête que ça c'est le mode par défaut,
mais on peut aussi rediriger l'entrée,
ce qui va être pris en entrée standard dans un logiciel,
et qu'on peut envoyer n'importe quoi,
ça peut être des informations de notre clavier par défaut,
mais ça peut être un fichier,
ça peut être un pipe dont on parlerait un petit peu plus tard,
ça peut être la sortie standard d'un autre programme,
ça peut être des données qui viennent d'une sockette,
ça peut être un autre device par exemple,
il y a une infinité de possibilités,
et alors la version la plus simple pour le voir dans un terminal,
c'est par exemple d'exécuter une commande
et de faire un chevron à gauche cette fois-ci,
et par exemple de mettre un fichier,
un fichier texte, je sais pas, fichier.exte par exemple,
il faut qu'il existe évidemment,
et bien là ce qui va se passer,
c'est que dès que le programme va être lancé,
tout le contenu de fichier texte va être envoyé dans l'entrée standard de ce logiciel.
Alors attention évidemment,
parce que là il y a une confusion qui est faite encore plus souvent,
c'est qu'on pense que les arguments qu'on envoie à une ligne de commande
passent par l'entrée standard.
Alors non, pour le coup quand vous lancez un programme avec des paramètres,
ces valeurs ne sont pas du tout lus sur l'entrée standard,
elles sont transmises directement au lancement du programme
par une liste d'arguments internes,
par exemple on sait c'est ce qu'on va appeler Arc-C, Arc-V,
souvent même dans le langage d'ailleurs,
c'est un peu la convention qu'on utilise,
et bien si vous appelez par exemple qu'on fait node plus loin index.js,
et bien là ce n'est pas du tout le contenu d'index.js,
point.js n'est pas envoyé en tant qu'entrée standard dans le programme node,
c'est simplement un argument, un paramètre qu'on va passer au logiciel node,
et c'est à lui de gérer ce qu'il va faire avec son paramètre,
ça ne passe pas du tout par l'entrée standard.
Alors ce qui est intéressant, c'est que ce concept là,
il est hyper puissant puisqu'on peut tout chêner en fait.
Comme je disais un petit peu, on va pouvoir tout en boiter comme des légos,
donc je vous prends un exemple très simple,
une commande Linux par exemple,
on va utiliser trois commandes séparées,
mais qui vont se chêner les unes les autres.
Donc on a une première commande qui s'appelle 4,
c'est at et avec un nom fichier ensuite,
ça ce que ça va faire, c'est que ça va les ouvrir ce fichier
et envoyer le contenu de ce fichier dans la sortie standard.
Ok ?
Ensuite on va avoir une autre commande qui s'appelle grep,
grep c'est pour des expressions régulières,
et donc on va mettre une chaîne de caractère,
par exemple la chaîne de caractère erreur,
et donc tout ce qui va rentrer dans l'entrée standard de grep,
eh bien on va le comparer par rapport à l'expression régulière
qu'on a donnée à grep en paramètres cette fois-ci,
et grep pour chaque ligne,
si ça correspond à l'expression régulière que lui a été passée,
eh bien il va laisser passer la ligne, sinon il va la filtrer.
Et enfin on a une dernière commande qui s'appelle double EC,
qui est world count,
et pareil on peut lui passer un paramètre qui est le paramètre L,
et donc world count ça va permettre de compter chacune des lignes
qu'il reçoit dans son entrée standard.
Et donc quand on va enchaîner tout ça,
alors comment est-ce qu'on les enchaîne avec un opérateur qui s'appelle un pipe,
c'est la petite barre verticale que vous avez,
eh bien quand vous faites par exemple 4 data.txt,
pipe grep erreur, pipe wc tiré L,
eh bien ces trois programmes, ils vont coopérer ensemble,
sans même le savoir,
ils vont simplement se préoccuper de leur propre entrée standard
et leur propre sortie standard.
Et donc qu'est-ce qui va se passer ?
Eh bien 4 va envoyer le contenu du fichier data.txt,
on peut imaginer que c'est des logs ou des choses comme ça,
avec plein de lignes,
grep il va recevoir tout ce fichier,
et il va trier chaque ligne,
est-ce que ça contient le mot erreur ou pas,
et wc word count,
il va simplement compter les lignes pour chaque ligne
où grep aura bien laissé passer,
puisque ça contenait le mot erreur.
Et donc qu'est-ce que ça nous donne ce truc là ?
Ça nous donne pour un fichier donné,
combien de lignes contenant le mot erreur se trouvent dans ce fichier.
Si on veut par exemple vérifier qu'il y en est zéro,
pour savoir si tout s'est bien passé dans notre fichier de logs.
Voilà, c'est trois commandes simples qui sont chaînées,
et qui montrent un petit peu comment fonctionne l'entrée et la sortie standard
de chacun de ces petits programmes.
Alors il y a quand même un canal de communication dont je ne vous ai pas parlé,
et c'est l'erreur standard, c'est STD-R.
C'est globalement la même chose que le STD-OUT,
donc la sortie standard,
mais les programmes vont avoir pour consigne
de n'envoyer que des erreurs,
que lorsque des choses se passent mal,
donc il va fonctionner de la même manière
dès qu'il va avoir quelque chose qui se passe mal,
il va l'envoyer dans ce canal d'erreur standard.
Voilà, et donc quand vous vous écrivez un programme,
par exemple on va prendre un programme en node,
node il est capable de lancer d'autres processus,
et ces autres processus qui sont des logiciels,
par exemple FFMPEG, ça peut être peu pétir,
ça peut être plein de choses, Chrome, peu importe,
et bien chacun de ces petits logiciels,
selon comment vous les utilisez,
ils vont envoyer des données,
ils vont attendre des données dans leur entrée standard,
et bien vous pouvez lancer trois logiciels
depuis votre logiciel node,
écoutez chacune des sorties standards,
et décidez de faire des actions en fonction des retours
de l'un ou de l'autre,
et vous pouvez également écouter chacune de leur canal d'erreur standard
pour savoir si un logiciel a un problème ou peu importe.
Donc vous pouvez orchestrer plusieurs logiciels,
vous pouvez décider de les faire communiquer entre eux
en les reliant par l'entrée standard et leur sortie standard,
bref vous pouvez faire tout ça,
simplement on a la limite de chaque logiciel à une entrée standard,
une sortie standard et un canal d'erreur standard,
mais on peut les orchestrer de la manière qu'on veut.
Alors je fais un petit disclaimer quand même,
puisque là on a parlé de terminal, de logiciels, etc.
Mais qu'est-ce qui se passe quand on lance un logiciel
depuis une interface graphique ?
Eh bien en fait quand vous vous double cliquez sur une application,
il n'y a en général aucun terminal d'affiché.
Le résultat c'est que la sortie standard,
elle n'a nulle part où renvoyer ces informations,
la sortie d'erreur standard non plus,
et l'entrée standard ne provient pas du clavier,
donc en réalité en général ces sorties
sont tout simplement redirigées vers un espace vide,
qui s'appelle par exemple sur linux slash dev slash nulle,
et donc ça va tomber dans l'oubli directement ces infos,
et vont être complètement oubliés de la machine.
Et c'est pour ça que par exemple un programme graphique,
il va souvent être obligé d'écrire dans des fichiers de logs
et des fichiers d'erreurs si jamais il veut laisser une trace,
puisque la plupart du temps,
comme il est exécuté directement depuis l'interface graphique,
il n'a aucune sortie standard ou sortie d'erreur de brancher.
Voilà, je pense qu'on a fait un bon petit tour d'horizon
de ce que sont les entrées et les sorties standards,
j'espère que vous aurez appris quelque chose,
n'hésitez pas à me faire des retours dans les commentaires sur Spotify
ou quand vous voyez passer l'épisode, 10h Apple Podcast, peu importe.
Pensez à laisser évidemment un avis 5 étoiles
pour aider à faire remonter le podcast,
et moi je vous donne rendez-vous la semaine prochaine
pour un prochain épisode du podcast,
et évidemment, venez faire un tour sur code-h.com
pour retrouver tous nos articles de blogs,
tous nos épisodes de podcast,
et surtout, tous nos cours complets pour apprendre des techno de A à Z,
il y en a pour tous les niveaux,
donc venez faire un tour, vous n'allez pas être déçu.
A la semaine prochaine, prenez soin de vous, salut !

Les infos glanées

Je suis une fonctionnalité encore en dévelopement

Signaler une erreur

Code-Garage

Découvrons ensemble des sujets passionnants autour du métier de dev et de la programmation en général !
Tags
Card title

Lien du podcast

[{'term': 'Technology', 'label': None, 'scheme': 'http://www.itunes.com/'}]

Go somewhere