Path: ...!news.mixmin.net!proxad.net!feeder1-2.proxad.net!cleanfeed1-b.proxad.net!nnrp5-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> <62ce256c$0$22264$426a34cc@news.free.fr> <871qupxml4.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 16:45:21 +0200
Lines: 157
Message-ID: <62ceda82$0$24807$426a34cc@news.free.fr>
Organization: Guest of ProXad - France
NNTP-Posting-Date: 13 Jul 2022 16:45:22 CEST
NNTP-Posting-Host: 91.175.52.121
X-Trace: 1657723522 news-4.free.fr 24807 91.175.52.121:3961
X-Complaints-To: abuse@proxad.net
Bytes: 6837

In article <871qupxml4.fsf@universite-de-strasbourg.fr.invalid>,
 Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> wrote:

> Thomas <fantome.forums.tDeContes@free.fr.invalid> writes:
> 
> > 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 ...
> 
> C'est à toi de décider.

je ne me rend pas compte si ça rend la vie plus difficile pour ceux qui 
n'utilisent pas l'option (il faut ajouter un ".")

je ne me rendais pas compte pour l'ordre des options, mais puisque tu 
insistes et que vous êtes 2 à le vouloir, je vais probablement le faire 
quand-même.

> 
> > https://semver.org/
> > qu'il faut attendre la prochaine version majeure pour changer les 
> > options ?
> 
> Pour une application, ajouter ou modifier le sens des options est selon
> moi une changement d'API.

ok, il faudrait que je fasse un autre fil pour ça.

> 
> >> 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" ?
> 
> La seconde. Si un argument contient plusieurs options, la première
> nécessitant un argument d'option s'impose : l'argument de l'option est
> soit la suite, soit l'argument suivant.

(si l'argument suivant est une option, que fait getopt() ?)

ce que je voulais dire c'est qu'à la relecture c'est pas évident du 
tout, il faut déchiffrer.
c'est qqch que j'évite au maximum.


> >> 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, ...
> 
> Bon c'est quand même pas la mer à boire.

ça fait bcp plus usine à gaz que l'analyse linéaire,
donc - entre autres - plus difficile à debugger et à maintenir.

bon, si c'est nécessaire on va se le farcir ...

> Voilà ce que ça donnerait (dans
> un langage imaginaire)
> 
>     # argc et tableau argv fournis (arguments du prog à partir de 1)
>     optind = 1
>     opt_v = opt_ni = opt_od = False
>     dir = "/valeur/par/défaut"
>     # analyser toutes les options
>     while optind < argc and argv[optind][0] == "-":
>         if argv[optind] in ["-v", "--verbose"]:
>             opt_v = True; optind += 1
>         elif argv[optind] in ["-ni", "--new-iork"]:

:-D
c'est "--noninteractive"
(je ne sais pas pourquoi il a choisi ça plutôt que le classique GUI/CLI.)

>             opt_ni = True; optind += 1
>         elif argv[optind] in ["-od", "--output-dir"] and optind+1 < argc:
>             opt_od = True; dir = argv[optind+1]; optind += 2
>         else:
>             wtf ("option inconnue")
>     # vérifier la cohérence
>     if opt_n == False and opd_od == True:
>         wtf ("-od sans -ni")
>     if optind == argc:
>         wtf ("pas de gui_file")

si je te suis bien, tu considères qu'il n'est pas important de traiter 
"--" ?

> 
> On peut affiner le cas d'erreur où "-od" est le dernier élément.

hé oui ! là tu utilises argv[optind+1] sans vérifier qu'il existe !
(je ne connais pas bien C, peut-être qu'en C ça passe.)

> On peut
> aussi tester la duplication des options (si le opt_x est déjà True).

dans ce cas là on doit faire quoi ? ignorer ou une erreur ?

> On
> peut aussi prévoir "-oddir" (ça complique le test et la logique pour
> l'incrémentation de optind), etc.

celui là je te propose de ne pas le faire.
surtout que si j'ai bien lu getopt(), ça ne sont que 2 cas, et il y a 
toutes sortes de caractères possibles comme séparateur.

> 
> Le test de cohérence final a exactement la meme structure que celui que
> tu fais en analysant les arguments (sauf qu'il teste seulement les
> différents booléens).

je ne dirais pas "exactement", mais je crois que ça va aller.

> 
> Si tu veux autoriser des options après les gui_files, c'est un peu plus
> compliqué (il faut mémoriser la position du premier gui_file, et tout
> décaler dès que tu trouves une option).

amha, si on veut respecter getopt(), il faut faire ça. mais bon, c'est 
une usine à gaz, quoi.
c'est assez facile de tout re-parcourir en sautant les "-", mais il faut 
aussi mémoriser la position de l'argument de "-od" pour le sauter aussi.

> 
> (À mon avis, ce n'est pas assez gratifiant pour se passer de getopt() ou
> s'écarter de ses conventions, mais chacun son truc.)

je ne comprend pas cette phrase.

> 
> > getopt(), en plus d'ajouter une dépendance
> 
> C'est Posix, il y a de fortes chances que la dépendance soit déjà
> satisfaite.

je programme en Ada, et ça ne fait pas partie de la norme Ada. donc ça 
me fait dépendre de mon compilateur via ses "suppléments".
ça peut être gênant pour ceux qui voudraient utiliser un autre 
compilateur que le mien.


une autre usine à gaz serait de traiter chaque option que je prend en 
charge une à la fois, et pour chacune parcourir tous les arguments à 
chaque fois.

-- 
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/