Flux et redirections

Complément - il y a un troisième flux que le cours ne mentionne pas

Ton prof parle de deux flux. En réalité tout programme Unix naît avec trois tuyaux branchés dessus. On les appelle des descripteurs de fichier (file descriptors, souvent abrégés fd) et ils sont numérotés.

Pourquoi séparer 1 et 2 alors que les deux s'affichent au même endroit ?

Analogie : imagine une usine. Le tapis roulant qui sort les produits finis, c'est stdout. La sonnerie d'alarme quand une machine casse, c'est stderr. Les deux "sortent" de l'usine et arrivent dans le même hangar, donc de loin tu ne vois pas la différence. Mais le jour où tu veux emballer les produits finis dans des cartons, tu ne veux surtout pas emballer la sonnerie avec.

Concrètement :

ls dossier_qui_existe dossier_bidon > resultat.txt

Le contenu du dossier qui existe part dans resultat.txt (c'est stdout, donc c'est lui qui est redirigé). Le message d'erreur, lui, s'affiche quand même à l'écran : il est passé par stderr, que tu n'as pas redirigé.

Pour rediriger les erreurs, on préfixe l'opérateur par le numéro du flux :

commande 2> erreurs.txt      # les erreurs dans un fichier
commande 2> /dev/null        # les erreurs à la poubelle
commande > tout.txt 2>&1     # les erreurs rejoignent la sortie normale
commande &> tout.txt         # raccourci bash du précédent

/dev/null est un fichier spécial : tout ce qu'on y écrit disparaît. C'est le trou noir du système. On l'appelle parfois "le puits sans fond".

Complément - la philosophie derrière le pipe

Le pipe (en français on dit tube) branche la sortie standard d'une commande directement sur l'entrée standard de la suivante. Rien ne passe par le disque, tout transite en mémoire.

ls -l | grep ".txt" | wc -l

Traduction ligne à ligne :

1. ls -l produit la liste détaillée des fichiers
2. grep ".txt" reçoit cette liste et ne garde que les lignes contenant .txt
3. wc -l reçoit ces lignes et les compte (wc = word count, -l = lines)

Résultat : le nombre de fichiers .txt du dossier.

L'analogie de la chaîne de montage. Chaque commande Unix est un ouvrier spécialisé qui sait faire une seule chose, mais parfaitement. grep filtre. sort trie. wc compte. cut découpe des colonnes. Aucun ne sait tout faire, et c'est volontaire. Le pipe, c'est le tapis roulant qui les relie. La puissance ne vient pas des ouvriers, elle vient du fait qu'on peut les assembler dans n'importe quel ordre.

C'est la philosophie Unix, formulée par Doug McIlroy en 1978 : écris des programmes qui font une chose et la font bien ; écris des programmes qui travaillent ensemble ; écris des programmes qui manipulent du texte, parce que le texte est une interface universelle.

Retiens bien ce dernier point. Si toutes les commandes échangent du texte brut, alors n'importe laquelle peut parler à n'importe quelle autre. C'est exactement pour ça que le terminal reste plus puissant qu'une interface graphique quarante ans après : dans une interface graphique, tu ne peux faire que ce que le développeur a prévu comme bouton.

À faire

• Ouvre le manuel de la commande touch, et utilise-la pour créer un fichier vide appelé fichier_touch.txt.
• Vérifie que le fichier a bien été créé avec la commande ls.

Complément - man, le réflexe à installer maintenant

man = manual. C'est la documentation officielle, installée sur ta machine, qui fonctionne sans internet. Dans un manuel :

Les manuels sont découpés en sections numérotées. man 1 printf te donne la commande shell, man 3 printf la fonction du langage C. D'où les notations que tu croiseras dans la doc, du type open(2).

Si le manuel est trop dense, commande --help donne souvent un résumé d'une page. Et apropos redirection cherche par mot-clé quand tu ne connais pas le nom de la commande.

Prends l'habitude de lire man avant de chercher sur internet. Ça te paraîtra lent au début, puis ça deviendra plus rapide qu'ouvrir un navigateur. Et le jour où tu seras sur une machine distante sans interface graphique, tu n'auras que ça.

Question du cours

Que veut dire « GUI » ?

À faire

• Trouve l'éditeur de texte par défaut installé sur ta machine.
• Crée un nouveau fichier fichier_editeur.txt, ajoute une ligne dedans, sauvegarde-le et ferme-le.

À faire

Exécute la commande suivante :

while true; do echo "coucou" ; sleep 2 ; done

Que se passe-t-il ? Exécute Ctrl-C dans le terminal : tu viens d'interrompre la commande.

Essaie ensuite d'ouvrir un éditeur de texte graphique :

gedit

Complément - décortiquer while true; do ... done

C'est ta première boucle shell. Mot à mot :

while true est donc une boucle dont la condition est vraie par construction : une boucle infinie. En Python, tu écrirais exactement la même chose :

import time
while True:
    print("coucou")
    time.sleep(2)

Note la différence de syntaxe : le shell délimite ses blocs par des mots-clés (do / done), Python par l'indentation. Même logique, deux habillages.

Complément - gérer les jobs, et les trois raccourcis à ne pas confondre

Commandes de gestion des jobs :

jobs          # liste les jobs du shell courant
fg %1         # ramène le job 1 au premier plan (foreground)
bg %1         # relance le job 1 en arrière-plan (background)
kill %1       # termine le job 1
nohup cmd &   # lance en arrière-plan ET survit à la fermeture du terminal

Et surtout, trois raccourcis que tout le monde confond au début :

La troisième ligne mérite un développement, parce qu'on lit souvent que Ctrl+D « arrête le processus en cours », ce qui est trompeur.

Ctrl+D ne tue rien. Il dit au programme : "l'entrée standard est terminée, il n'y aura plus rien à lire". Si le programme en question est ton shell, un shell qui n'a plus rien à lire n'a plus de raison d'exister, donc il se ferme — d'où l'impression qu'il "ferme le terminal". Mais la cause est différente.

Vérifie la différence en deux essais :

cat               # sans argument : cat lit ton clavier et le recopie
# tape du texte, puis Entrée : il te le répète
# Ctrl+D : cat se termine proprement, tu as "fermé le robinet"

cat
# Ctrl+C : cat est interrompu de force

Même résultat apparent, deux mécanismes opposés. Cette distinction te servira beaucoup plus tard que tu ne le crois : elle est au cœur de la façon dont les programmes s'enchaînent dans un pipe.

À faire

Teste les commandes suivantes et explique ce qui se passe. À quoi sert la commande cat ?

echo "ligne 1"
echo "ligne 1" > sortie.txt
cat sortie.txt
echo "ligne 1" >> sortie.txt
cat sortie.txt
echo "ligne 2" >> sortie.txt
cat sortie.txt
echo "ligne 3" > sortie.txt
cat sortie.txt

Complément - à quoi sert vraiment cat

cat vient de concatenate, concaténer : mettre bout à bout. Sa fonction première n'est pas d'afficher un fichier, c'est de coller plusieurs fichiers en un seul flux :

cat partie1.txt partie2.txt partie3.txt > complet.txt

L'affichage à l'écran n'est qu'un effet de bord : quand tu écris cat fichier.txt, tu concatènes un seul fichier et le résultat part sur la sortie standard, qui est ton écran par défaut.

Trois choses à savoir en plus :

• cat sans argument lit ton clavier. Il attend sur l'entrée standard. D'où l'astuce pour écrire un fichier sans éditeur :
  TerminalCopier

  cat > note.txt
  je tape mon texte
  et une deuxième ligne
  # puis Ctrl+D pour terminer

• Ne pas utiliser cat sur un fichier long. Tout défile et tu ne peux pas remonter. Utilise less fichier.txt (navigation avec les flèches, / pour chercher, q pour quitter), ou head -n 20 / tail -n 20 pour les premières ou dernières lignes. tail -f journal.log suit un fichier en direct pendant qu'il se remplit — indispensable quand tu surveilleras des logs.
• Ne jamais faire cat sur un fichier binaire (une image, un exécutable). Ton terminal interprétera des octets aléatoires comme des codes de contrôle et deviendra illisible. Si ça t'arrive : tape reset à l'aveugle, puis Entrée.

Ajout personnel - pourquoi ce cours banal est en fait central

Tu apprends à rediriger des flux dans un TP d'introduction. Voici où tu retrouveras exactement la même chose :

• Masquer le bruit pendant une reconnaissance. nmap -p- cible 2>/dev/null envoie les erreurs à la poubelle pour ne garder que les résultats exploitables. Un pipe derrière (| grep open) et tu as une liste de ports ouverts propre.
• Effacer ses traces. Un attaquant qui obtient les droits root fait > /var/log/auth.log : un seul caractère et le journal d'authentification est vide. C'est précisément pour ça qu'en défense on envoie les logs en temps réel vers une autre machine (un serveur SIEM). Un journal stocké uniquement sur la machine compromise ne vaut rien.
• Construire des outils en une ligne. cat rockyou.txt | grep -E '^.{12,}$' | sort -u > longs.txt filtre une liste de mots de passe. Tu auras besoin d'exactement ça pour la V2 de ton Password Checker.
• Le danger de curl | bash. Beaucoup de tutoriels te disent d'installer un outil avec curl https://site.tld/install.sh | bash. Tu comprends maintenant ce que ça fait : télécharger du code et l'exécuter immédiatement, sans jamais le lire. Si le site est compromis, tu exécutes le code de l'attaquant avec tes droits. Le réflexe correct : curl -o install.sh https://..., puis less install.sh, puis exécuter si le contenu te convient.

C'est le genre de détail qui sépare quelqu'un qui récite des commandes de quelqu'un qui comprend ce qu'il fait.