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

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.

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.

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.

-onv => -o nv
-nvo dir => -n -v -o dir
-nvovn => -n -v -o vn

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. 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"]:
            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")

On peut affiner le cas d'erreur où "-od" est le dernier élément. On peut
aussi tester la duplication des options (si le opt_x est déjà True). On
peut aussi prévoir "-oddir" (ça complique le test et la logique pour
l'incrémentation de optind), etc.

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).

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).

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

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.

-- Alain.