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/

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.

Thomas , dans le message <62ce256c$0$22264$426a34cc@news.free.fr>, a
écrit :

accepter "-vn" comme "-v -n",
accepter "-odir" comme "-o dir",

est-ce que c'est qqch que les usagers utilisent bcp, ça ?

Oui.

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/

Thomas , dans le message <62ceda82$0$24807$426a34cc@news.free.fr>, a
écrit :

je ne me rendais pas compte pour l'ordre des options, mais puisque tu
insistes et que vous êtes 2 Í  le vouloir

Si c'est moi le deuxième, on ne peut pas vraiment dire que je le veuille, je
suis ce thread vraiment superficiellement, je ne sais même pas de quel
logiciel il s'agit, et je ne l'utiliserai probablement pas.

Et j'utilise bien d'autres programmes dont le système d'option ne suit pas
cette convention, Í  commencer par ffmpeg. Mais quand un programme suit la
convention et que je le sais, je l'utilise, et je ne suis pas le seul.

D'ailleurs, tout le monde connaͮt rm -rf.

In article <62cee3c1$0$22053$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> wrote:

Thomas , dans le message <62ceda82$0$24807$426a34cc@news.free.fr>, a
écrit :
> je ne me rendais pas compte pour l'ordre des options, mais puisque tu
> insistes et que vous êtes 2 Í  le vouloir

Si c'est moi le deuxième

non, c'est Olivier Miakinen.
je n'avais pas vu ton 1er msg au moment o͹ j'ai posté.

Et j'utilise bien d'autres programmes dont le système d'option ne suit pas
cette convention, Í  commencer par ffmpeg.

ah donc tu n'es pas forcément hostile Í  des choses différentes, super :-)

du coup, si je n'accepte pas "-odir", ça va ?


mais surtout, Est-ce que, Í  ton avis en tant qu'usager, ceci est
acceptable (c'est ça qu'Olivier avait soulevé) ?

$ ./rapid gui_file -v
Unexpected switch -v
Usage: ./rapid [-v] [gui_file]
       ./rapid [-v] -ni [-od output_directory] gui_file ...
$ ./rapid -ni -od p -v u
Unexpected switch -v
Usage: ./rapid [-v] [gui_file]
       ./rapid [-v] -ni [-od output_directory] gui_file ...
$ ./rapid -od p -ni -v u
Unexpected switch -od
Usage: ./rapid [-v] [gui_file]
      ./rapid [-v] -ni [-od output_directory] gui_file ...

Mais quand un programme suit la
convention et que je le sais, je l'utilise, et je ne suis pas le seul.

D'ailleurs, tout le monde connaͮt rm -rf.

tiens c'est bizarre !

usage: rm [-f | -i] [-dPRrvW] file ...

qu'est-ce que ça signifie ?
Nicolas, je veux dire, par différence avec :
usage: rm [-fidPRrvW] file ...

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

Le 13/07/2022 18:24, Thomas a écrit :

mais surtout, Est-ce que, Í  ton avis en tant qu'usager, ceci est
acceptable (c'est ça qu'Olivier avait soulevé) ?

$ ./rapid gui_file -v
Unexpected switch -v
Usage: ./rapid [-v] [gui_file]
       ./rapid [-v] -ni [-od output_directory] gui_file ...

Pour moi, il est tout Í  fait normal de refuser une option -v après
le premier argument qui n'est pas une option (gui_file).

Cela dit, le message « Unexpected switch -v » est inapproprié. Selon
que ta syntaxe accepte ou non plus d'un fichier, ce sera soit :
File not found '-v' (sauf bien sͻr si le fichier -v existe)
soit :
No more than one file! (gui_file -v)

$ ./rapid -ni -od p -v u
Unexpected switch -v
Usage: ./rapid [-v] [gui_file]
       ./rapid [-v] -ni [-od output_directory] gui_file ...

LÍ  ça me semble brutal pour l'utilisateur. Tant que tu en es Í  parser
des options et pas des fichiers, il n'y a Í  mon avis aucune raison
de refuser une option -v

$ ./rapid -od p -ni -v u
Unexpected switch -od
Usage: ./rapid [-v] [gui_file]
      ./rapid [-v] -ni [-od output_directory] gui_file ...

LÍ  aussi, encore que ta syntaxe est assez particulière. Comme Nicolas
je ne sais pas ce que fait ton logiciel et je ne l'utiliserai sans
doute jamais, seulement je crois comprendre que l'option -od ne peut
exister que dans le cas o͹ tu as déjÍ  l'option -ni, ce qui me semble
peu habituel.

Te serait-il possible d'accepter l'option -od dans tous les cas lors du
parsing, en disant juste 'attention cette option ne fait rien dans cette
version de la syntaxe' ? Bon, je ne suis pas sͻr que ce soit une bonne
idée non plus.

Ou alors tu changes la syntaxe pour qu'il y ait *une* sous-commande
obligatoire, plus les paramètres optionnels, et enfin les paramètres
positionnels. Par exemple :

Usage: ./rapid i [-v] gui_file
./rapid ni [-v] [-od output_directory] gui_file...

D'ailleurs, tout le monde connaͮt rm -rf.

tiens c'est bizarre !

usage: rm [-f | -i] [-dPRrvW] file ...

qu'est-ce que ça signifie ?
Nicolas, je veux dire, par différence avec :
usage: rm [-fidPRrvW] file ...

Les options -i et -f sont contradictoires : l'une demande confirmation
Í  chaque fichier alors que l'autre dit au contraire d'y aller par force
sans aucune demande de confirmation. Elles sont donc exclusives.


--
Olivier Miakinen

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

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.

[...]

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

Pas du tout, tu fais ce que tu veux, c'est juste une illustration du
fait que ce n'est pas très difficile.

[...]

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

[...]

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

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

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 ?

Au choix. Je préfère ignorer (ou warning au pire).

[...]

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.

C'est la même logique.

[...]

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

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.

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.

-- Alain.

Thomas , dans le message <62cef1d6$0$24817$426a34cc@news.free.fr>, a
écrit :

ah donc tu n'es pas forcément hostile Í  des choses différentes, super :-)

du coup, si je n'accepte pas "-odir", ça va ?

Ça dépend. Ton projet est aussi important que ffmpeg ?

mais surtout, Est-ce que, Í  ton avis en tant qu'usager, ceci est
acceptable (c'est ça qu'Olivier avait soulevé) ?

$ ./rapid gui_file -v
Unexpected switch -v

Comme Olivier l'a signalé : il faudrait traiter -v comme un argument normal.

In article <tamt6m$2338$1@cabale.usenet-fr.net>,
Olivier Miakinen <om+news@miakinen.net> wrote:

Le 13/07/2022 18:24, Thomas a écrit :
>
> mais surtout, Est-ce que, Í  ton avis en tant qu'usager, ceci est
> acceptable (c'est ça qu'Olivier avait soulevé) ?
>
> $ ./rapid gui_file -v
> Unexpected switch -v
> Usage: ./rapid [-v] [gui_file]
>        ./rapid [-v] -ni [-od output_directory] gui_file ...

Pour moi, il est tout Í  fait normal de refuser une option -v après
le premier argument qui n'est pas une option (gui_file).

je disais Í  Alain qu'amha il faut le faire si on veut "rester dans
l'esprit" de getopt(),
mais si je te comprend bien, ça n'a tellement pas d'importance qu'il ne
faut pas que je m'embête avec ça ? :-)

Cela dit, le message « Unexpected switch -v » est inapproprié. Selon
que ta syntaxe accepte ou non plus d'un fichier, ce sera soit :
File not found '-v' (sauf bien sͻr si le fichier -v existe)
soit :
No more than one file! (gui_file -v)

j'ai tendance Í  penser qu'en l'absence de "--", tout argument commençant
par "-" est une option, et que, sorties de la zone prévue pour elles,
elles sont mal positionnées.

ça me parait un peu cafouilleux de dire : les noms de fichier commençant
par "-" sont autorisés, Í  condition d'en trouver un qui ne commence pas
par "-" Í  mettre en 1er.


en gros, mon éducation Ada c'est : "avertir l'usager qu'il a peut-être
fait une erreur, et le laisser corriger - plutÍ´t que de choisir une
interprétation, et de prendre l'initiative de faire qqch que peut-être
il ne voulait pas".
je sais que les dev C ont une toute autre approche ...

typiquement, si je passe Í  getopt() plus tard, la même ligne de commande
changera de signification, sans qu'aucune des 2 ne fasse une erreur ...
ce qui me parait dangereux.

> $ ./rapid -ni -od p -v u
> Unexpected switch -v
> Usage: ./rapid [-v] [gui_file]
>        ./rapid [-v] -ni [-od output_directory] gui_file ...

LÍ  ça me semble brutal pour l'utilisateur. Tant que tu en es Í  parser
des options et pas des fichiers, il n'y a Í  mon avis aucune raison
de refuser une option -v

j'ai oublié de demander en passant : je peux garder le même "Usage:"
même s'il laisse penser que l'ordre est important ? l'important c'est
qu'en réalité ça ne soit pas le cas ?

> $ ./rapid -od p -ni -v u
> Unexpected switch -od
> Usage: ./rapid [-v] [gui_file]
>       ./rapid [-v] -ni [-od output_directory] gui_file ...

LÍ  aussi, encore que ta syntaxe est assez particulière. Comme Nicolas
je ne sais pas ce que fait ton logiciel et je ne l'utiliserai sans
doute jamais,

et je vous remercie tous de prendre du temps pour moi malgré ça :-))

(ce que j'espère au fond, c'est qu'un jour vous trouviez mon logiciel
utile et que vous constatiez le résultat de vos "contributions")

seulement je crois comprendre que l'option -od ne peut
exister que dans le cas o͹ tu as déjÍ  l'option -ni,

oui.
rappelles-toi, tu m'avais suggéré :
usage: rapid [-v] [ gui_file | -ni [-od dir] gui_file... ]

ce qui me semble
peu habituel.

ah ! ....

Te serait-il possible d'accepter l'option -od dans tous les cas lors du
parsing, en disant juste 'attention cette option ne fait rien dans cette
version de la syntaxe' ? Bon, je ne suis pas sͻr que ce soit une bonne
idée non plus.

tu veux dire, faire un avertissement au lieu d'une erreur ?
actuellement il fait un avertissement pour les options inconnues,
ce que j'ai transformé en erreur parce que ça me parait bcp plus sur
(voir plus haut).

Ou alors tu changes la syntaxe pour qu'il y ait *une* sous-commande
obligatoire, plus les paramètres optionnels, et enfin les paramètres
positionnels. Par exemple :

Usage: ./rapid i [-v] gui_file
./rapid ni [-v] [-od output_directory] gui_file...

oui, comme dans svn :-)
intéressant :-)

dans le fil "Gérer soi-même ses numéros de version" j'ai indiqué que je
voulais faire un "split" (ou un "fork", je ne sais pas comment tu
appelles ça), ce qui réglerais ce pb,
mais :
- j'essaye de faire en sorte que chaque commit soit du bon code en
fonction de mes connaissances du moment (et si possible même si je sais
que ça ne va pas durer, si ça ne demande pas trop de travail),
- il se peut que j'en ai besoin de toutes façons, si je demande Í  mon
"rapid-ni" de savoir faire d'autres choses, pour éviter de multiplier
les exécutables.

du coup, si je comprend bien :
- l'usage est que la sous-commande est sans "-", obligatoire, et tjr au
début,
- ensuite, les paramètres optionnels, tous avec "-" et tous
interchangeables,
- enfin les paramètres positionnels -> ça peut être autre chose qu'une
liste de fichiers ? pourquoi "positionnels" ?
(et d'après toi ils peuvent commencer par "-" sauf le 1er ?)

> usage: rm [-f | -i] [-dPRrvW] file ...
>
> qu'est-ce que ça signifie ?

Les options -i et -f sont contradictoires : l'une demande confirmation
Í  chaque fichier alors que l'autre dit au contraire d'y aller par force
sans aucune demande de confirmation. Elles sont donc exclusives.

merci :-)

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