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

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/