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/