Un peu d'histoire

Linux est créé par Linus Torvalds, alors étudiant finlandais, qui annonce son "petit projet, juste un hobby" sur un forum Usenet en août 1991. Le noyau Linux s'appuie sur les outils du projet GNU, lancé dès 1983 par Richard Stallman pour créer un système d'exploitation entièrement libre. Bash (Bourne Again SHell), l'interpréteur de commandes le plus utilisé sous Linux, est écrit par Brian Fox en 1989 pour ce même projet GNU, en remplacement libre du shell Bourne (sh) créé en 1977 chez AT&T.

Pourquoi apprendre Linux et Bash aujourd'hui

Linux fait tourner la quasi-totalité des serveurs web et du cloud (AWS, Google Cloud, Azure), la majorité des supercalculateurs, et sert de base au système Android. Le terminal et Bash restent l'outil de travail quotidien de tout développeur backend, ingénieur DevOps ou administrateur système : c'est souvent plus rapide et plus puissant qu'une interface graphique, et c'est indispensable dès qu'on touche à un serveur distant.

Ce que vous allez apprendre

• Comprendre ce qu'est réellement un shell et pourquoi Bash s'interpose entre toi et Linux
• Distinguer un builtin (cd, echo) d'un programme externe (ls) et savoir pourquoi ça change leur comportement
• Lire et utiliser le code de sortie ($?) d'une commande pour savoir si elle a réussi
• Enchaîner des commandes avec ;, && et || selon la logique de succès/échec
• Retrouver et rejouer une commande passée grâce à history et Ctrl+R

Dans quel contexte ?

Imagine un développeur qui vient de recevoir l'accès SSH à son premier serveur de production Ubuntu, sans aucune interface graphique. Tout ce qu'il peut faire pour vérifier que le service nginx tourne, lire un fichier de configuration ou redémarrer un processus doit passer par ce terminal noir qui n'affiche qu'une invite clignotante. Comprendre le shell, c'est comprendre l'unique porte d'entrée vers cette machine.

Le shell, c'est quoi au juste ?

D'abord, une image simple. Quand tu ouvres un terminal, tu ne parles pas directement à Linux : tu parles à un programme intermédiaire, le shell, qui traduit ce que tu tapes en actions concrètes.

C'est un peu comme un interprète placé entre toi et le système d'exploitation. Bash est le shell le plus répandu, mais ce n'est pas le seul : zsh, fish ou sh existent aussi et se ressemblent beaucoup une fois les bases acquises.

Shell	Où on le trouve	Particularité
sh (Bourne shell)	Quasi tous les Unix, scripts #!/bin/sh	Le plus basique, standard POSIX
bash	Shell par défaut de la plupart des distributions Linux	Le plus répandu, riche en fonctionnalités
zsh	macOS (depuis Catalina), option sur Linux	Complétion et thèmes très avancés (ex: Oh My Zsh)
fish	Installé volontairement	Syntaxe simplifiée, pensé pour l'interactif

Pourquoi taper plutôt que cliquer ?

Cliquer semble plus simple au premier abord, mais chaque clic est un geste isolé, difficile à reproduire exactement. Une interface graphique cache en réalité des raccourcis puissants : enchaîner des commandes, les répéter, les combiner.

Le terminal donne un contrôle total et surtout reproductible : une commande tapée peut être copiée, partagée, mise dans un script, alors qu'une suite de clics ne se documente pas aussi bien.

Une fois ça posé, il faut distinguer deux types de commandes

Bash ne traite pas toutes les commandes de la même façon. Certaines sont intégrées au shell lui-même (les builtins, comme cd ou echo) et n'ont besoin d'aucune installation.

D'autres sont des programmes externes stockés quelque part sur le disque, comme ls (situé dans /usr/bin/ls). Cette différence explique pourquoi une commande peut se comporter différemment d'un shell à l'autre : un builtin appartient au shell, un programme externe est partagé par tous.

Il reste un point essentiel avant de pouvoir enchaîner des commandes : le code de sortie

Chaque commande, en terminant, renvoie discrètement un nombre : 0 signifie "tout s'est bien passé", n'importe quel autre chiffre signale une erreur. Tu ne le vois pas apparaître à l'écran, mais il est toujours là, accessible via $?.

C'est cette valeur cachée qui permettra plus tard de dire à Bash "fais B seulement si A a réussi". Comprendre ce mécanisme dès maintenant évite bien des scripts qui échouent en silence, sans qu'on comprenne pourquoi.

Le piège à éviter

Ne confonds pas l'historique des commandes (ce que tu as tapé, consultable avec history) avec la mémoire du système : fermer le terminal ne supprime rien de ce qui a déjà été exécuté, mais l'historique local, lui, peut se perdre si tu ne le sauvegardes pas correctement. Un autre piège classique de débutant : croire que cd et ls sont le même genre de commande, alors que l'un est un builtin et l'autre un exécutable — une nuance qui explique certains comportements déroutants une fois qu'on écrit des scripts plus complexes.

Maintenant que tu sais ce qu'est le shell et comment il "réfléchit" tes commandes, la prochaine étape logique est de savoir où tu te situes dans le système de fichiers et comment t'y déplacer : c'est exactement l'objet de la leçon suivante.