Path: ...!newsreader4.netcologne.de!news.netcologne.de!news.mixmin.net!proxad.net!feeder1-2.proxad.net!usenet-fr.net!.POSTED!not-for-mail From: Olivier Miakinen Newsgroups: fr.comp.os.unix Subject: =?UTF-8?Q?Re:_r=c3=a8gle_pour_=c3=a9crire_les_=22usage:_...=22?= Date: Wed, 13 Jul 2022 23:40:15 +0200 Organization: There's no cabale Lines: 149 Message-ID: References: <62c8c4eb$0$24781$426a74cc@news.free.fr> <875yk3xsbg.fsf@universite-de-strasbourg.fr.invalid> <62ce256c$0$22264$426a34cc@news.free.fr> <871qupxml4.fsf@universite-de-strasbourg.fr.invalid> <62ceda82$0$24807$426a34cc@news.free.fr> <62cee3c1$0$22053$426a74cc@news.free.fr> <62cef1d6$0$24817$426a34cc@news.free.fr> <62cf1ed0$0$9166$426a34cc@news.free.fr> NNTP-Posting-Host: 220.12.205.77.rev.sfr.net Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Trace: cabale.usenet-fr.net 1657748415 73850 77.205.12.220 (13 Jul 2022 21:40:15 GMT) X-Complaints-To: abuse@usenet-fr.net NNTP-Posting-Date: Wed, 13 Jul 2022 21:40:15 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 In-Reply-To: <62cf1ed0$0$9166$426a34cc@news.free.fr> Bytes: 7891 Le 13/07/2022 21:36, Thomas a écrit : >> Cela dit, le message « Unexpected switch -v » est inapproprié. Selon >> que ta syntaxe accepte ou non plus d'un fichier, ce sera soit : >> File not found '-v' (sauf bien sûr si le fichier -v existe) >> soit : >> No more than one file! (gui_file -v) > > j'ai tendance à penser qu'en l'absence de "--", tout argument commençant > par "-" est une option, et que, sorties de la zone prévue pour elles, > elles sont mal positionnées. Pour fixer le contexte, je précise que je ne connais pas le monde Ada, mais que je n'ai pas non plus une connaissance théorique des normes Posix. Simplement je travaille sur des machines Unix depuis près de 35 ans, ce qui me donne une habitude « pratique » de la plupart des commandes. Cette habitude fait que j'ai certaines attentes quant au comportement lors de la lecture des arguments, et que la plupart du temps je ne suis pas surpris par le comportement réel. Ce sont ces attentes, satisfaites dans l'immense majorité des cas, que je décris ici. > ça me parait un peu cafouilleux de dire : les noms de fichier commençant > par "-" sont autorisés, à condition d'en trouver un qui ne commence pas > par "-" à mettre en 1er. Alors moi, voici comment je me représente les choses et ce n'est pas cafouilleux dans mon esprit, même si j'ai peut-être une représentation fausse. Pour moi, la syntaxe d'une commande est pratiquement toujours de la forme : NOM [OPTIONS] [ARGUMENTS] Où : NOM Est le nom unique de la commande, le plus souvent tout en minuscules, et toujours sans espaces. OPTIONS Est une liste d'options dont chacune commence par un tiret, parfois deux tirets pour les options longues. Chaque option est soit sans paramètre, soit avec un paramètre unique. Qu'il y ait ou non un paramètre est propre à l'option et ne change pas pour cette commande et cette option. Exemples : -a --nom-long -a param -aparam --nom-long=param Et lorsque toutes les options courtes sont sur un seul caractère je sais que je peux les combiner dans n'importe quel ordre. Exemples : ls -lt -r ls -r -l -t ls -tlr ARGUMENTS Est une liste d'arguments, souvent des noms de fichiers traités dans l'ordre l'un après l'autre. Par ailleurs, je sais que l'on passe automatiquement de la partie OPTIONS à la partie ARGUMENTS dès que l'on trouve un mot qui commence par autre chose qu'un tiret (en dehors des paramètres d'options bien sûr). Et que si le premier argument doit commencer par un tiret, alors il faut mettre explicitement un séparateur -- entre les deux parties (ce séparateur étant bien sûr autorisé même si le premier argument ne pose pas de souci. Voilà, c'est ça ma représentation implicite, qui marche la plupart du temps sauf pour certaines commandes que je trouve alors bizarres tant que je ne m'y suis pas habitué. C'est le même genre de représentation implicite qui fait que lorsque je vois un mammifère je ne m'attends pas à ce qu'il ponde des œufs... jusqu'au jour où je tombe sur un ornithorynque. >> [...] > > j'ai oublié de demander en passant : je peux garder le même "Usage:" > même s'il laisse penser que l'ordre est important ? l'important c'est > qu'en réalité ça ne soit pas le cas ? À mon avis, oui. Ceux qui veulent respecter l'ordre le respecteront et tout ira bien pour eux, tout comme ceux qui pensent que l'ordre n'a pas d'importance. Ça me rappelle cette anecdote d'un logiciel où le message « press any key to continue » aurait été changé en « press a key to continue », parce que des utilisateurs ne savaient pas trouver la touche « any » mais qu'ils savaient trouver la touche « a ». Pour moi, dans ma représentation implicite, ce qui est dans [OPTIONS] est par défaut indépendant de l'ordre, alors que ce qui est dans [ARGUMENTS] est par défaut sensible à l'ordre. > [...] >> >> Là aussi, encore que ta syntaxe est assez particulière. Comme Nicolas >> je ne sais pas ce que fait ton logiciel et je ne l'utiliserai sans >> doute jamais, > > et je vous remercie tous de prendre du temps pour moi malgré ça :-)) > > (ce que j'espère au fond, c'est qu'un jour vous trouviez mon logiciel > utile et que vous constatiez le résultat de vos "contributions") Pour le moment tu ne nous en as pas dit assez pour qu'on sache à quoi ça pourrait nous servir (ou alors tu l'as fait dans une autre discussion, que je n'ai pas lue ou que j'ai oubliée à cause de ma mauvaise mémoire). > [...] >> >> Te serait-il possible d'accepter l'option -od dans tous les cas lors du >> parsing, en disant juste 'attention cette option ne fait rien dans cette >> version de la syntaxe' ? Bon, je ne suis pas sûr que ce soit une bonne >> idée non plus. En fait, ce que j'imagine, c'est que le parsing des options se fasse d'une façon indépendante. Tu vois un '-ni', tu mets un flag 'with_ni'. Tu vois un '-od /tmp', tu mets le flag 'with_od' et tu stockes '/tmp' dans 'the_od'. Tu vois un '-v', tu mets le flag 'with_v'. Et c'est seulement à la fin que tu fais des tests de cohérence : si tu vois à ce moment-là que le booléen 'with_od' a été positionné mais pas 'with_ni', c'est là que tu peux balancer un message d'erreur. > tu veux dire, faire un avertissement au lieu d'une erreur ? > actuellement il fait un avertissement pour les options inconnues, > ce que j'ai transformé en erreur parce que ça me parait bcp plus sur > (voir plus haut). Avertissement ou erreur, c'est toi qui décides. Mais tu t'es simplifié le parsing des options en faisant une seule boucle et sans te poser des questions, jusqu'au moment où tu as enfin *tous* les éléments en main pour le message le plus approprié. >> Ou alors tu changes la syntaxe pour qu'il y ait *une* sous-commande >> obligatoire, plus les paramètres optionnels, et enfin les paramètres >> positionnels. Par exemple : >> >> Usage: ./rapid i [-v] gui_file >> ./rapid ni [-v] [-od output_directory] gui_file... > > oui, comme dans svn :-) > intéressant :-) Je n'avais pas osé parlé de cvs :-) Note qu'ils font déjà partie des cas particuliers qui ne rentrent pas dans les cases de ma représentation implicite. > [...] Désolé, j'ai déjà beaucoup écrit, je n'ai pas le courage de continuer. -- Olivier Miakinen