Deutsch English Français Italiano |
<62ce256c$0$22264$426a34cc@news.free.fr> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!3.eu.feeder.erje.net!feeder.erje.net!proxad.net!feeder1-2.proxad.net!cleanfeed1-b.proxad.net!nnrp4-1.free.fr!not-for-mail From: Thomas <fantome.forums.tDeContes@free.fr.invalid> Newsgroups: fr.comp.os.unix Mail-Copies-To: nobody Subject: Re: =?UTF-8?Q?r=C3=A8gle_pour_=C3=A9crire?= les "usage: ..." References: <62c8c4eb$0$24781$426a74cc@news.free.fr> <tab00r$v6d7$1@dont-email.me> <62c98a7b$0$18716$426a74cc@news.free.fr> <87a69ix9rl.fsf@universite-de-strasbourg.fr.invalid> <62cc5318$0$18751$426a34cc@news.free.fr> <tahkuf$6ob$1@cabale.usenet-fr.net> <875yk3xsbg.fsf@universite-de-strasbourg.fr.invalid> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit User-Agent: MT-NewsWatcher/3.5.3b3 (Intel Mac OS X) Date: Wed, 13 Jul 2022 03:52:44 +0200 Lines: 160 Message-ID: <62ce256c$0$22264$426a34cc@news.free.fr> Organization: Guest of ProXad - France NNTP-Posting-Date: 13 Jul 2022 03:52:44 CEST NNTP-Posting-Host: 91.175.52.121 X-Trace: 1657677164 news-4.free.fr 22264 91.175.52.121:10153 X-Complaints-To: abuse@proxad.net Bytes: 6988 In article <875yk3xsbg.fsf@universite-de-strasbourg.fr.invalid>, Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> wrote: > Olivier Miakinen <om+news@miakinen.net> writes: > > > Le 11/07/2022 18:43, Thomas répondait à Alain Ketterlin : > > [...] > >>> Si l'ordre des options est sans importance, il vaut peut-être mieux en > >>> donner une liste linéaire, comme le fait en général --help (ou le man). > >>> Un synopsis "mkdir [-m mode] [-p]" aurait l'air d'imposer l'ordre. > >> > >> ah ben tant mieux : > >> j'ai horreur de l'analyse de texte, et la lecture des arguments en fait > >> partie. > >> ça me parait bcp moins compliqué à faire avec un ordre imposé. > > Je te comprends : dans ton cas, tu peux analyser les arguments avec une > cascade de if. et, j'ai beau y réfléchir, c'est bien plus simple que ce que tu me décris ci-dessous ... (mais évidement ça a l'inconvénient indiqué par Olivier) > Mais imagine que tu écrives "ls" : difficile d'exiger les > options dans l'ordre alphabétique. et encore pire, dans un autre ordre ! je comprend, et tant mieux que getopt() existe pour ça. mais moi, vu que l'analyse de texte m'embête à un point que tu peux pas imaginer, moins il y a d'options à gérer mieux je me porte, donc j'ai tendance à aller vers moins d'option : par ex, que diriez vous si je décidais de rendre dir obligatoire ? usage: rapid [-v] -ni dir gui_file ... au lieu de usage: rapid [-v] -ni [-od dir] gui_file ... > > > Permets-moi d'être en complet désaccord avec toi sur ce point, parce que > > là l'usage est quasiment universel, du moins pour toutes les options avec > > tiret. > > > > Je veux dire que si la syntaxe proposée est : > > usage: rapid [-v] -ni [-od dir] gui_file... > > > > alors je m'attendrais à ce que toutes ces écritures soient autorisées : > > rapid -v -ni -od dir gui_file... > > rapid -ni -v -od dir gui_file... > > rapid -ni -od dir -v gui_file... > > rapid -v -od dir -ni gui_file... > > rapid -od dir -v -ni gui_file... > > rapid -od dir -ni -v gui_file... ces 3 là sont particulièrement difficiles à gérer (-od avant -ni), et peut-être aussi le cas où il faut indiquer une erreur parce que -od est à la fin. > > > > Bien sûr je m'interdirais seulement de mettre 'dir' ailleurs que juste > > derrière '-od', ou de mettre 'gui_file...' ailleurs qu'à la fin. > > C'est la vision Posix, telle qu'elle est implémentée dans la fonction > getopt() -- sauf que les options doivent être mono-caractère. Dans ce > cas (options -v -n -o), on écrirait (en C) : le pb c'est que, le mainteneur précédent a eu l'idée (je ne sais pas comment) de faire des versions courtes et des versions longues de chaque option, mais avec des versions courtes de 2 lettres ... (par ex -od/--output-directory) peut-être ne connaissait-il pas getopt() ? (moi non plus) et maintenant qu'il a fait ça, je crois comprendre d'après https://semver.org/ qu'il faut attendre la prochaine version majeure pour changer les options ? je n'en suis pas certain, et à ce propos je veux bien un peu plus d'infos si vous en avez, sur la "public API" : Comment la determine-t-on ? Jusqu'à quel degré est-il permis de modifier marginalement des choses dans l'interface utilisateur, tant qu'il ne perd pas de fonctionnalité globalement ? > > while ((opt = getopt(argc, argv, "vno:")) != -1) /* ":" = argument */ > { > switch (opt) > { > case 'v': > ... > break; > /* ... */ > case 'o': > whatever = optarg; > ... > break; > default: > wtf ("option inconnue"); > } > } > if (optind >= argc) > wtf ("il faut au moins un gui_file"); > /* les "gui_file" sont argv[optind] etc. */ > > getopt() s'occupe de tout, y compris permuter les éléments de argv si > nécessaire pour permettre "rapid gui1 -v gui2", > traiter l'option "--" > pour permettre ensuite un fichier appelé "-guifile" ou même "-v", j'ai pensé à ça, et ce que j'ai pensé c'est que dans ce cas l'usager peut tjr "échapper" le "-" en écrivant "./-guifile ./-v". penses-tu que je devrais le programmer quand-même ? (pour éviter le "Unknown or misplaced switch".) > accepter "-vn" comme "-v -n", > accepter "-odir" comme "-o dir", est-ce que c'est qqch que les usagers utilisent bcp, ça ? parce que moi je trouve ça plutôt embêtant, avec notamment : "-onv" = "-o -n -v", ou "-onv" => dir = "nv" ? > etc. J'en > oublie sûrement. > > Tellement pratique qu'on cherche rarement ailleurs. Par contre cela > oblige à la fin à vérifier la cohérence (si il y a une option -o il faut > qu'il y ait aussi l'option -n). donc il faut gérer l'erreur à ce moment là (-o en trop ou -n manquant ?). il faut aussi vérifier s'il y a des options non autorisées qui ont été utilisées, vérifier je ne sais pas bien comment s'il y a bien eu un argument pour -o, ... en fait, ce qui me dérange le plus c'est ça : j'ai déjà qqch qui ressemble pas mal à ce que tu dis (au lieu de tester chaque résultat de getopt() ça teste chaque argument), sauf que c'est tout troué. une simple analyse linéaire permet de bien tout border, et en principe de boucher tous les trous, et de ne rien laisser passer qui n'ait pas été prévu. getopt(), en plus d'ajouter une dépendance, ne me permet pas de bien tout border et de ne rien laisser passer, parce que pour ça il y a une condition nécessaire supplémentaire : bien maitriser cet outil ... -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/