Re: règle pour écrire les "usage: ..."

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/