Terminal et shell

Sur Proxmox et les VM Debian du lab, presque tout passe par un terminal. Que ce soit la console locale d’un nœud, la console Proxmox d’une VM, ou une session SSH depuis mon PC, c’est là que je lis les logs, que je corrige une config et que je lance les scripts d’arrêt ou de diagnostic. Cette page rappelle ce qu’est un terminal par rapport à un shell, pourquoi Bash est le défaut sur mes machines, et comment lire les premières commandes sans se noyer dans l’historique des shells Unix.

Terminal : console locale et émulateurs

Historiquement, on parlait à la machine via des terminaux physiques séparés de l’unité centrale. Aujourd’hui, sur un serveur sans interface graphique — le cas normal d’un Proxmox ou d’une VM « serveur » — on travaille en mode texte. Localement, les consoles virtuelles (Ctrl+Alt+F1 et suivantes) donnent un écran noir classique. À distance, on utilise un émulateur de terminal sur le poste de travail (Windows Terminal, GNOME Terminal, etc.) qui parle au serveur via SSH. Sur une VM, la « console » affichée dans l’UI Proxmox simule l’accès local : pratique pour le réseau cassé, mais ce n’est pas le même outil que l’émulateur sur ton laptop.

En administration, on ouvre souvent plusieurs sessions en parallèle — utilisateurs différents, machines différentes, un œil sur les logs pendant qu’on édite un fichier. Le réflexe utile, c’est de savoir où on est connecté (hostname dans le prompt, IP) avant de coller une commande destructive.

Shell : Bash sur les nœuds du lab

Le shell est le programme qui lit ce que tu tapes et le traduit en appels au noyau. Il permet aussi d’enchaîner des commandes (tubes, redirections) et d’automatiser via des scripts. Sous Linux, Bash est le défaut le plus courant ; la ligne correspondante se trouve dans /etc/passwd. Bash apporte l’historique, la complétion avec Tab, l’interruption avec Ctrl+C, et le code de retour $? — autant d’outils que j’utilise dès qu’un one-liner devient un petit script dans /usr/local/bin.

D’autres shells existent (sh, zsh, fish…). Sur le lab je reste sur Bash sauf besoin précis : c’est ce que je retrouve sur Debian/Proxmox, et ça évite de maintenir plusieurs habitudes pour le même parc.

Premières commandes

À la connexion, le prompt affiche en général l’utilisateur, la machine et le répertoire courant. Sa forme vient souvent de la variable $PS1 ; $SHELL indique le shell lancé. Quelques commandes pour se situer :

echo "$SHELL"
/bin/bash --version
pwd
ls
type ls
type cd

ls liste le répertoire. Certaines commandes sont internes au shell (cd, type) ; d’autres sont des binaires trouvés via $PATH (/usr/bin/id, etc.). type nom dit laquelle tu appelles — utile quand un alias ou un chemin custom masque la commande attendue. La doc locale reste man commande ; les options courtes (-l) et longues (--help) suivent en général les conventions POSIX.

Dès qu’on lit un log ou qu’on filtre une sortie, les tubes | et les redirections (>, >>, 2>) deviennent le quotidien. La page suivante, Fichiers, enchaîne sur l’arborescence et les permissions — le même fil, un cran plus bas dans le système.