Un rapide cours de shell pour Commown - retour accueil
git clone git://bebou.netlib.re/cours-shell
Log | Files | Refs |
commit b85ac2730a34addaf4fa44cca74032d8bd9a56a5 parent fa2db1d6074e1842947fbf2f0d124b4b23d0ddfe Auteurice: Arthur Pons <arthur.pons@unistra.fr> Date: Mon, 24 Mar 2025 16:43:15 +0100 Avancées sur le cours Diffstat:
| M | prez.slides | | | 256 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--- |
1 file changed, 249 insertions(+), 7 deletions(-)
diff --git a/prez.slides b/prez.slides @@ -2,22 +2,264 @@ + + Manier le shell : + Aller au delà du copier/coller de + Stack Overflow - Titre : - Exemple de présentation +› Objectifs -› première slide +Être : -blabla -blabla + * une rampe de lancement pour une personne utilisant déjà le shell mais ne + sachant pas vraiment ce qu'elle fait avec. + * un cours collant à la norme POSIX + quelques trucs (vraiment) pratiques + * un cours démystifiant certaine parties du shell pour montrer que c'est un + langage "comme les autres" dans le sens qu'il est étudiable comme les + autres. -› Seconde slide +Ne pas être : + + * une description exhaustive de ce que fait le shell + * un cours de shell pas POSIX (bash, zsh etc) + * un cours pour débutant·es +› Documents de références + +Le manuel de dash + + man sh + +Le manuel de ksh élagués de ses parties pas POSIX + + man ksh + + +› Vocabulaire + +POSIX + + Un ensemble de standards proposés fin des années 80 pour uniformiser les + éléments fondamentaux des Unix de l'époque. Ils partaient tous un peu trop + dans leurs coins. Détaille l'arbo de fichier, ce qu'est un thread, l'appel + système pour créer un fichier, le format des regex mais aussi : le + fonctionnement du shell et les outils que l'on utilise habituellement + dedans. + + Attention, si la plupart des Unix se conforment plutôt bien à la norme + aucun ne le fait strictement et il peut y avoir des surprises. + +› Vocabulaire + +Shell + + À la fois le langage de commandes des Unix et les programmes qui l'interprête. + Il y a un seul langage shell POSIX mais plusieurs interpréteurs pour (dash, + busybox sh, bash etc). + + Puisque le shell est fait pour appeler d'autre programme on entend parfois + ces autres programmes être inclus dans ce que l'on appelle du shell. Par exemple + un script avec un seul appel à grep est du shell mais c'est surtout grep. + Cette distinction peut prêter confusion puisque l'on nomme parfois "shell + pur" un script ne contenant pas d'autre langage de programmation et + d'autres fois un programme shell n'appelant strictement aucune commande + extérieure à l'interpréteur de shell (rarement utile). + + Tous les scripts shell ne sont pas du bash. Ces deux mots ne sont pas + synonymes. +› Vocabulaire + +Terminal (ou tty) + + La machine à travers laquelle on communique avec l'ordinateur. + Historiquement une machine physique principalement composée d'un clavier et + d'un périphérique permettant de voir les résultats de nos commandes + (imprimante + papier ou écran). Aujourd'hui on utilise des "émulateurs de + terminaux" qui pour la plupart simule et étendent le VT100, un terminal très + populaire et influent. + + +› La navigation + +La plupart du temps on script en shell POSIX (du moins je recommande) mais on +interagit en shell plus sophistiqués. Ces shells permettent : + +De naviguer dans l'historique de commandes ctrl+r +Revenir au début de la ligne ctrl+a +De supprimer un mot en arrière ctrl+w +D'utiliser les arguments de la cmd prec !* +Ou juste le dernier $_ + +D'avoir de l'autocomplétion très sympa (surtout zsh) : + + zsh + + +› Séquences d'échappement + +Les shells ont deux modes, interactifs et pas interactifs. Dans le mode +interactifs les terminaux interprêtent des caractères spéciaux nommés "séquences +d'échappement". + +Elles permettent par exemple de mettre de la couleur ou de déplacer le curseur. +C'est comme ça que fonctionnent des applications comme vim. + + printf "1234\033[91men rouge\033[0m5678";read + printf "123456789[4Dtruc";read + + vim | vim - + + + +› C'est quoi une commande ? + +On créé un dossier non lisible et non parcourable par d'autres que root + + sudo mkdir -p dir1 + sudo chmod -rx dir1 + sudo touch dir1/a + +Et maintenant on essaye de regarder dedans ou d'entrer dedans + + ls -l dir1 + cd dir1 + +Normal, et pourtant + + sudo ls -l dir1 + sudo cd dir1 + +› C'est quoi une commande ? + +Le shell va passer par trois étapes dans cet ordre : + + 1. Est-ce que c'est une fonction ? + 2. Est-ce que c'est une commande "builtin" ? + 3. est-ce que c'est un programme externe ? + +Une fonction : + + fonction() { + seq 10 + } + fonction + +Un builtin : + + Une commande implémentées directement dans l'interpréteur shell. + Historiquement l'un des buts était d'éviter de forker trop souvent pour des + commandes habituelles. C'est pour ça que `echo` ou `test` sont généralement + des builtins. + +Les fonctions et les buitlin ont la particularité d'être exécutés dans le même +processus que le shell courant. Il n'y a pas de fork. + + strace sh -c 'echo truc' 2>&1 | grep fork + + strace sh -c 'ls' 2>&1 | grep fork + +Au passage cette explication explique également pourquoi on ne peut pas + + sudo echo "truc" > dir1/a + +› Et les alias ? + +Encore une autre histoire : + + Réécriture directe de la commande avant de faire toute chose avec + +› Les descripteurs de fichier + +Pourquoi est-ce que : + + cat + +Les descripteurs de fichier sont des entiers qui, dans le contexte du +processus, désignent des fichiers du système. Par défaut les processus en ont +trois : + + * 0 : Entrée standard + * 1 : Sortie standard + * 2 : Sortie d'erreur + +Les shells connectent ces trois entrées/sorties au terminal. Le shell lit ce +que l'on insère dans le terminal et met les résultats (standards et erreurs) +dans le terminal. Tout se passe au même endroit. + +Quand un programme fork il hérite de ses descripteurs fichiers de son parent. + +› Les redirections + +Vous connaissez les bases. + +Positionnement : + + redir cmd redir + +Donc ces commandes sont équivalentes : + + seq 10 > a + > a seq 10 #très rare + + < a tac + tac < a + +› Les globs + +Ne sont pas des regex ! parfois appelés "shell patterns" (dans le manuel de +dash du moins). + +Une syntaxe rapide et pratique pour écrire une méta chaîne de caractère. + + * `*` n'importe quel caractère + * `?` un ou zéro caractère + * `[]` ouvre et ferme une classe de caractère + +Supprimera tous les fichiers commençant par un chiffre et un tiret puis +n'importe et terminant par `.jp` suivant d'un caractère ou pas, suivi de `g`. + + rm [0-9]-*.jp?g + +Match le fichier `9-truc.jpg.jpag`. + +On les retrouve parfois dans d'autres commandes, par exemple find : + + find -name '*.pdf' + find -regex '.*\.pdf$' + + + + + +› xargs + +L'une de mes commandes préféré, utile pour scripter et de manière interactive. + +Admettons que vous sachiez retrouver les gros pdf de votre home : + + find $HOME -maxdepth 4 -name '*.pdf' -size +10M + +Et que vous voulez les ouvrir pour les consulter. Il faudrait pouvoir mettre le +résultat de cette commande en argument d'une autre. C'est pour ça qu'xargs existe. + + find $HOME -maxdepth 4 -name '*.pdf' -size +10M | xargs -I{} zathura "{}" + +Les globs !!! +La redirection qui nécessite root +Les coreutils gotchas +Les différentes syntaxes de redir (< cmd ou cmd <) +Les heredoc +Les enchainements && et || +Les conditionnels (diff test [, valeur de retour des cmd) +Grouper les commandes pour grouper leurs stdout +Xargs +Différences alias, builtins, fonctions, cmd +Subshell et ce que ça fait +Les erreurs de bases (gestion noms de fichiers, les boucles quifont n'imp, les conditions un peu difficiles à écrire) -blablabla du rouge plus de blabla