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

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

Thomas <fantome.forums.tDeContes@free.fr.invalid> writes:
 

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() ?)

 
-o -v => -v est l'argument de l'option -o (idem "-o-v")

-o -- c'est pareil ? c'est un cas particulier où -- n'interrompt pas les
options ?

 

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.

 
Je pense que c'est juste le contraire : on lit de gauche à droite, il
suffit de savoir quelle option a un argument.

on peut déchiffrer comme un dev C peut déchiffrer du C.
mais si on n'a pas besoin de déchiffrer c'est quand même plus pratique
...

sérieusement, tu pratiques ça souvent, de ne pas mettre d'espace pour
tes arguments d'option alors que c'est autorisé ?

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

 
Voilà ce qu'il faut ajouter :
 
        elif argv[optind] == "--":
            optind += 1
            break

d'après ce que je comprend ailleurs, si, c'est important, alors je
l'ajoute.
(j'attend ta confirmation à la 1ere question.)

 

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 !

 
Si si, c'est vérifié.

exact, désolé, erreur d'attention.

(À 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.

 
Cela signifie : moi j'utiliserais getopt() à la place

j'ai failli dire que je ne peux pas parce que ça ne supporte qu'un seul
caractère,
mais en fait il semble que celle de gnat ne repique pas directement
celle de Posix en C, et qu'elle accepte les options de plusieurs
caractères.
il faut juste que je vérifie que c'est compatible avec les options
longues, et ça devrais être envisageable.

j'espère juste que celle de gnat ne s'écarte pas trop des conventions de
celle de Posix (mais elle en implemente au moins une partie que je
n'aurais pas fait sinon)

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/ada/libgnat/g-comlin.ads;
h=a2d90716a4ce7c8460161984786a3dc00292a754;hb=refs/heads/releases/gcc-12
( https://urlpetite.net/?eps )
l 44-83, 366-500

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.

 
Il doit y a avoir quelque chose d'équivalent à getopt. En python il y a
un module getopt et aussi argparse. Si ça n'y est pas, tu peux râler
auprès des développeurs de la bibliothèque standard.

c'est une chose qui est envisageable :-)

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