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.
[...]
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 ?
[...]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")
[...]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 :-)
[...]
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.
[...]
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 ?
[...]
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")
[...]
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 :-)
[...]
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.
[...]
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 ?
[...]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")
[...]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 :-)
[...]
Pour fixer le contexte, je précise que je ne connais pas le monde Ada,
mais que je n'ai pas non plus une connaissance théorique des normes
Posix. Simplement je travaille sur des machines Unix depuis près de
35 ans, ce qui me donne une habitude « pratique » de la plupart des
commandes. Cette habitude fait que j'ai certaines attentes quant au
comportement lors de la lecture des arguments, et que la plupart du
temps je ne suis pas surpris par le comportement réel.
Ce sont ces attentes, satisfaites dans l'immense majorité des cas, que
je décris ici.
ç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.
Alors moi, voici comment je me représente les choses et ce n'est pas
cafouilleux dans mon esprit, même si j'ai peut-être une représentation
fausse. Pour moi, la syntaxe d'une commande est pratiquement toujours
de la forme :
NOM [OPTIONS] [ARGUMENTS]
O͹ :
NOM
Est le nom unique de la commande, le plus souvent tout en minuscules,
et toujours sans espaces.
OPTIONS
Est une liste d'options dont chacune commence par un tiret, parfois
deux tirets pour les options longues. Chaque option est soit sans
paramètre, soit avec un paramètre unique. Qu'il y ait ou non un
paramètre est propre Í l'option et ne change pas pour cette commande
et cette option. Exemples :
-a
--nom-long
-a param
-aparam
--nom-long=param
Par ailleurs, je sais que l'on passe automatiquement de la partie OPTIONS
Í la partie ARGUMENTS dès que l'on trouve un mot qui commence par autre
chose qu'un tiret (en dehors des paramètres d'options bien sÍ»r).
Pour fixer le contexte, je précise que je ne connais pas le monde Ada,
mais que je n'ai pas non plus une connaissance théorique des normes
Posix. Simplement je travaille sur des machines Unix depuis près de
35 ans, ce qui me donne une habitude « pratique » de la plupart des
commandes. Cette habitude fait que j'ai certaines attentes quant au
comportement lors de la lecture des arguments, et que la plupart du
temps je ne suis pas surpris par le comportement réel.
Ce sont ces attentes, satisfaites dans l'immense majorité des cas, que
je décris ici.
ç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.
Alors moi, voici comment je me représente les choses et ce n'est pas
cafouilleux dans mon esprit, même si j'ai peut-être une représentation
fausse. Pour moi, la syntaxe d'une commande est pratiquement toujours
de la forme :
NOM [OPTIONS] [ARGUMENTS]
O͹ :
NOM
Est le nom unique de la commande, le plus souvent tout en minuscules,
et toujours sans espaces.
OPTIONS
Est une liste d'options dont chacune commence par un tiret, parfois
deux tirets pour les options longues. Chaque option est soit sans
paramètre, soit avec un paramètre unique. Qu'il y ait ou non un
paramètre est propre Í l'option et ne change pas pour cette commande
et cette option. Exemples :
-a
--nom-long
-a param
-aparam
--nom-long=param
Par ailleurs, je sais que l'on passe automatiquement de la partie OPTIONS
Í la partie ARGUMENTS dès que l'on trouve un mot qui commence par autre
chose qu'un tiret (en dehors des paramètres d'options bien sÍ»r).
Pour fixer le contexte, je précise que je ne connais pas le monde Ada,
mais que je n'ai pas non plus une connaissance théorique des normes
Posix. Simplement je travaille sur des machines Unix depuis près de
35 ans, ce qui me donne une habitude « pratique » de la plupart des
commandes. Cette habitude fait que j'ai certaines attentes quant au
comportement lors de la lecture des arguments, et que la plupart du
temps je ne suis pas surpris par le comportement réel.
Ce sont ces attentes, satisfaites dans l'immense majorité des cas, que
je décris ici.
ç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.
Alors moi, voici comment je me représente les choses et ce n'est pas
cafouilleux dans mon esprit, même si j'ai peut-être une représentation
fausse. Pour moi, la syntaxe d'une commande est pratiquement toujours
de la forme :
NOM [OPTIONS] [ARGUMENTS]
O͹ :
NOM
Est le nom unique de la commande, le plus souvent tout en minuscules,
et toujours sans espaces.
OPTIONS
Est une liste d'options dont chacune commence par un tiret, parfois
deux tirets pour les options longues. Chaque option est soit sans
paramètre, soit avec un paramètre unique. Qu'il y ait ou non un
paramètre est propre Í l'option et ne change pas pour cette commande
et cette option. Exemples :
-a
--nom-long
-a param
-aparam
--nom-long=param
Par ailleurs, je sais que l'on passe automatiquement de la partie OPTIONS
Í la partie ARGUMENTS dès que l'on trouve un mot qui commence par autre
chose qu'un tiret (en dehors des paramètres d'options bien sÍ»r).
Thomas 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.
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é.
(À 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
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.
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.
> 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é.
>> (À 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
> 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.
Thomas 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.
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é.
(À 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
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.
Pour fixer le contexte,
je précise que je ne connais pas le monde Ada,
mais que je n'ai pas non plus une connaissance théorique des normes
Posix. Simplement je travaille sur des machines Unix depuis près de
35 ans, ce qui me donne une habitude « pratique » de la plupart des
commandes. Cette habitude fait que j'ai certaines attentes quant au
comportement lors de la lecture des arguments, et que la plupart du
temps je ne suis pas surpris par le comportement réel.
Ce sont ces attentes, satisfaites dans l'immense majorité des cas, que
je décris ici.
Le 13/07/2022 21:36, Thomas a écrit :ç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.
Alors moi, voici comment je me représente les choses et ce n'est pas
cafouilleux dans mon esprit, même si j'ai peut-être une représentation
fausse. Pour moi, la syntaxe d'une commande est pratiquement toujours
de la forme :
NOM [OPTIONS] [ARGUMENTS]
O͹ :
NOM
OPTIONS
Est une liste d'options dont chacune commence par un tiret,
-a param
-aparam
--nom-long=param
ARGUMENTS
Est une liste d'arguments, souvent des noms de fichiers traités dans
l'ordre l'un après l'autre.
Par ailleurs, je sais que l'on passe automatiquement de la partie OPTIONS
Í la partie ARGUMENTS dès que l'on trouve un mot qui commence par autre
chose qu'un tiret (en dehors des paramètres d'options bien sÍ»r).
Et que
si le premier argument doit commencer par un tiret, alors il faut mettre
explicitement un séparateur -- entre les deux parties (ce séparateur
étant bien sÍ»r autorisé même si le premier argument ne pose pas de souci.
VoilÍ , c'est ça ma représentation implicite, qui marche la plupart du
temps sauf pour certaines commandes que je trouve alors bizarres tant
que je ne m'y suis pas habitué. C'est le même genre de représentation
implicite qui fait que lorsque je vois un mammifère je ne m'attends
pas Í ce qu'il ponde des ½ufs... jusqu'au jour o͹ je tombe sur un
ornithorynque.
Ça me rappelle cette anecdote d'un logiciel o͹
le message « press any key to continue » aurait été changé en « press
a key to continue », parce que des utilisateurs ne savaient pas trouver
la touche « any » mais qu'ils savaient trouver la touche « a ».
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")
Pour le moment tu ne nous en as pas dit assez pour qu'on sache Í quoi ça
pourrait nous servir (ou alors tu l'as fait dans une autre discussion,
que je n'ai pas lue ou que j'ai oubliée Í cause de ma mauvaise mémoire).
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.
En fait, ce que j'imagine, c'est que le parsing des options se fasse d'une
façon indépendante. Tu vois un '-ni', tu mets un flag 'with_ni'. Tu vois un
'-od /tmp', tu mets le flag 'with_od' et tu stockes '/tmp' dans 'the_od'.
Tu vois un '-v', tu mets le flag 'with_v'. Et c'est seulement Í la fin que
tu fais des tests de cohérence : si tu vois Í ce moment-lÍ que le booléen
'with_od' a été positionné mais pas 'with_ni', c'est lÍ que tu peux balancer
un message d'erreur.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).
Avertissement ou erreur, c'est toi qui décides. Mais tu t'es simplifié le
parsing des options en faisant une seule boucle et sans te poser des
questions, jusqu'au moment o͹ tu as enfin *tous* les éléments en main
pour le message le plus approprié.
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.
Note qu'ils font déjÍ partie des cas particuliers qui ne rentrent pas
dans les cases de ma représentation implicite.[...]
Désolé, j'ai déjÍ beaucoup écrit, je n'ai pas le courage de continuer.
Pour fixer le contexte,
je précise que je ne connais pas le monde Ada,
mais que je n'ai pas non plus une connaissance théorique des normes
Posix. Simplement je travaille sur des machines Unix depuis près de
35 ans, ce qui me donne une habitude « pratique » de la plupart des
commandes. Cette habitude fait que j'ai certaines attentes quant au
comportement lors de la lecture des arguments, et que la plupart du
temps je ne suis pas surpris par le comportement réel.
Ce sont ces attentes, satisfaites dans l'immense majorité des cas, que
je décris ici.
Le 13/07/2022 21:36, Thomas a écrit :
> ç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.
Alors moi, voici comment je me représente les choses et ce n'est pas
cafouilleux dans mon esprit, même si j'ai peut-être une représentation
fausse. Pour moi, la syntaxe d'une commande est pratiquement toujours
de la forme :
NOM [OPTIONS] [ARGUMENTS]
O͹ :
NOM
OPTIONS
Est une liste d'options dont chacune commence par un tiret,
-a param
-aparam
--nom-long=param
ARGUMENTS
Est une liste d'arguments, souvent des noms de fichiers traités dans
l'ordre l'un après l'autre.
Par ailleurs, je sais que l'on passe automatiquement de la partie OPTIONS
Í la partie ARGUMENTS dès que l'on trouve un mot qui commence par autre
chose qu'un tiret (en dehors des paramètres d'options bien sÍ»r).
Et que
si le premier argument doit commencer par un tiret, alors il faut mettre
explicitement un séparateur -- entre les deux parties (ce séparateur
étant bien sÍ»r autorisé même si le premier argument ne pose pas de souci.
VoilÍ , c'est ça ma représentation implicite, qui marche la plupart du
temps sauf pour certaines commandes que je trouve alors bizarres tant
que je ne m'y suis pas habitué. C'est le même genre de représentation
implicite qui fait que lorsque je vois un mammifère je ne m'attends
pas Í ce qu'il ponde des ½ufs... jusqu'au jour o͹ je tombe sur un
ornithorynque.
Ça me rappelle cette anecdote d'un logiciel o͹
le message « press any key to continue » aurait été changé en « press
a key to continue », parce que des utilisateurs ne savaient pas trouver
la touche « any » mais qu'ils savaient trouver la touche « a ».
>> 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")
Pour le moment tu ne nous en as pas dit assez pour qu'on sache Í quoi ça
pourrait nous servir (ou alors tu l'as fait dans une autre discussion,
que je n'ai pas lue ou que j'ai oubliée Í cause de ma mauvaise mémoire).
>> 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.
En fait, ce que j'imagine, c'est que le parsing des options se fasse d'une
façon indépendante. Tu vois un '-ni', tu mets un flag 'with_ni'. Tu vois un
'-od /tmp', tu mets le flag 'with_od' et tu stockes '/tmp' dans 'the_od'.
Tu vois un '-v', tu mets le flag 'with_v'. Et c'est seulement Í la fin que
tu fais des tests de cohérence : si tu vois Í ce moment-lÍ que le booléen
'with_od' a été positionné mais pas 'with_ni', c'est lÍ que tu peux balancer
un message d'erreur.
> 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).
Avertissement ou erreur, c'est toi qui décides. Mais tu t'es simplifié le
parsing des options en faisant une seule boucle et sans te poser des
questions, jusqu'au moment o͹ tu as enfin *tous* les éléments en main
pour le message le plus approprié.
>> 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.
Note qu'ils font déjÍ partie des cas particuliers qui ne rentrent pas
dans les cases de ma représentation implicite.
> [...]
Désolé, j'ai déjÍ beaucoup écrit, je n'ai pas le courage de continuer.
Pour fixer le contexte,
je précise que je ne connais pas le monde Ada,
mais que je n'ai pas non plus une connaissance théorique des normes
Posix. Simplement je travaille sur des machines Unix depuis près de
35 ans, ce qui me donne une habitude « pratique » de la plupart des
commandes. Cette habitude fait que j'ai certaines attentes quant au
comportement lors de la lecture des arguments, et que la plupart du
temps je ne suis pas surpris par le comportement réel.
Ce sont ces attentes, satisfaites dans l'immense majorité des cas, que
je décris ici.
Le 13/07/2022 21:36, Thomas a écrit :ç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.
Alors moi, voici comment je me représente les choses et ce n'est pas
cafouilleux dans mon esprit, même si j'ai peut-être une représentation
fausse. Pour moi, la syntaxe d'une commande est pratiquement toujours
de la forme :
NOM [OPTIONS] [ARGUMENTS]
O͹ :
NOM
OPTIONS
Est une liste d'options dont chacune commence par un tiret,
-a param
-aparam
--nom-long=param
ARGUMENTS
Est une liste d'arguments, souvent des noms de fichiers traités dans
l'ordre l'un après l'autre.
Par ailleurs, je sais que l'on passe automatiquement de la partie OPTIONS
Í la partie ARGUMENTS dès que l'on trouve un mot qui commence par autre
chose qu'un tiret (en dehors des paramètres d'options bien sÍ»r).
Et que
si le premier argument doit commencer par un tiret, alors il faut mettre
explicitement un séparateur -- entre les deux parties (ce séparateur
étant bien sÍ»r autorisé même si le premier argument ne pose pas de souci.
VoilÍ , c'est ça ma représentation implicite, qui marche la plupart du
temps sauf pour certaines commandes que je trouve alors bizarres tant
que je ne m'y suis pas habitué. C'est le même genre de représentation
implicite qui fait que lorsque je vois un mammifère je ne m'attends
pas Í ce qu'il ponde des ½ufs... jusqu'au jour o͹ je tombe sur un
ornithorynque.
Ça me rappelle cette anecdote d'un logiciel o͹
le message « press any key to continue » aurait été changé en « press
a key to continue », parce que des utilisateurs ne savaient pas trouver
la touche « any » mais qu'ils savaient trouver la touche « a ».
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")
Pour le moment tu ne nous en as pas dit assez pour qu'on sache Í quoi ça
pourrait nous servir (ou alors tu l'as fait dans une autre discussion,
que je n'ai pas lue ou que j'ai oubliée Í cause de ma mauvaise mémoire).
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.
En fait, ce que j'imagine, c'est que le parsing des options se fasse d'une
façon indépendante. Tu vois un '-ni', tu mets un flag 'with_ni'. Tu vois un
'-od /tmp', tu mets le flag 'with_od' et tu stockes '/tmp' dans 'the_od'.
Tu vois un '-v', tu mets le flag 'with_v'. Et c'est seulement Í la fin que
tu fais des tests de cohérence : si tu vois Í ce moment-lÍ que le booléen
'with_od' a été positionné mais pas 'with_ni', c'est lÍ que tu peux balancer
un message d'erreur.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).
Avertissement ou erreur, c'est toi qui décides. Mais tu t'es simplifié le
parsing des options en faisant une seule boucle et sans te poser des
questions, jusqu'au moment o͹ tu as enfin *tous* les éléments en main
pour le message le plus approprié.
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.
Note qu'ils font déjÍ partie des cas particuliers qui ne rentrent pas
dans les cases de ma représentation implicite.[...]
Désolé, j'ai déjÍ beaucoup écrit, je n'ai pas le courage de continuer.
-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 ?
[...]
sérieusement, tu pratiques ça souvent, de ne pas mettre d'espace pour
tes arguments d'option alors que c'est autorisé ?
-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 ?
[...]
sérieusement, tu pratiques ça souvent, de ne pas mettre d'espace pour
tes arguments d'option alors que c'est autorisé ?
-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 ?
[...]
sérieusement, tu pratiques ça souvent, de ne pas mettre d'espace pour
tes arguments d'option alors que c'est autorisé ?
-a param
(peux tu me confirmer pour -a -- si jamais tu réponds avant Alain stp ?)
[...]Ça me rappelle cette anecdote d'un logiciel o͹
le message « press any key to continue » aurait été changé en « press
a key to continue », parce que des utilisateurs ne savaient pas trouver
la touche « any » mais qu'ils savaient trouver la touche « a ».
ça ressemble Í une réaction d'autiste :-)
[...]
dans mes souvenirs j'en ai parlé dans le fil "gérer des fichiers log"
qui a environ 1 an puisqu'il commence Í s'effacer de mon serveur.
si jamais ça t'intéresse, voilÍ les liens pertinents :
Page d'accueil du projet :
http://savannah.nongnu.org/projects/rapid/
[...]
Avertissement ou erreur, c'est toi qui décides. Mais tu t'es simplifié le
parsing des options en faisant une seule boucle et sans te poser des
questions, jusqu'au moment o͹ tu as enfin *tous* les éléments en main
pour le message le plus approprié.
ce que ça m'inspire, c'est que cette boucle, si elle doit être la même
partout, elle peut être factorisée ...
getopt() pourrait fournir une structure de données en forme de
map (carte ?), contenant toutes les données qu'on peut vouloir trouver
sur la ligne de commande d'une façon qui soit organisée.
Désolé, j'ai déjÍ beaucoup écrit, je n'ai pas le courage de continuer.
il n'en restait plus bcp,
mais si tu avais encore des choses Í dire et que tu as de nouveau du
courage, ça sera avec plaisir :-))
-a param
(peux tu me confirmer pour -a -- si jamais tu réponds avant Alain stp ?)
[...]
Ça me rappelle cette anecdote d'un logiciel o͹
le message « press any key to continue » aurait été changé en « press
a key to continue », parce que des utilisateurs ne savaient pas trouver
la touche « any » mais qu'ils savaient trouver la touche « a ».
ça ressemble Í une réaction d'autiste :-)
[...]
dans mes souvenirs j'en ai parlé dans le fil "gérer des fichiers log"
qui a environ 1 an puisqu'il commence Í s'effacer de mon serveur.
si jamais ça t'intéresse, voilÍ les liens pertinents :
Page d'accueil du projet :
http://savannah.nongnu.org/projects/rapid/
[...]
Avertissement ou erreur, c'est toi qui décides. Mais tu t'es simplifié le
parsing des options en faisant une seule boucle et sans te poser des
questions, jusqu'au moment o͹ tu as enfin *tous* les éléments en main
pour le message le plus approprié.
ce que ça m'inspire, c'est que cette boucle, si elle doit être la même
partout, elle peut être factorisée ...
getopt() pourrait fournir une structure de données en forme de
map (carte ?), contenant toutes les données qu'on peut vouloir trouver
sur la ligne de commande d'une façon qui soit organisée.
Désolé, j'ai déjÍ beaucoup écrit, je n'ai pas le courage de continuer.
il n'en restait plus bcp,
mais si tu avais encore des choses Í dire et que tu as de nouveau du
courage, ça sera avec plaisir :-))
-a param
(peux tu me confirmer pour -a -- si jamais tu réponds avant Alain stp ?)
[...]Ça me rappelle cette anecdote d'un logiciel o͹
le message « press any key to continue » aurait été changé en « press
a key to continue », parce que des utilisateurs ne savaient pas trouver
la touche « any » mais qu'ils savaient trouver la touche « a ».
ça ressemble Í une réaction d'autiste :-)
[...]
dans mes souvenirs j'en ai parlé dans le fil "gérer des fichiers log"
qui a environ 1 an puisqu'il commence Í s'effacer de mon serveur.
si jamais ça t'intéresse, voilÍ les liens pertinents :
Page d'accueil du projet :
http://savannah.nongnu.org/projects/rapid/
[...]
Avertissement ou erreur, c'est toi qui décides. Mais tu t'es simplifié le
parsing des options en faisant une seule boucle et sans te poser des
questions, jusqu'au moment o͹ tu as enfin *tous* les éléments en main
pour le message le plus approprié.
ce que ça m'inspire, c'est que cette boucle, si elle doit être la même
partout, elle peut être factorisée ...
getopt() pourrait fournir une structure de données en forme de
map (carte ?), contenant toutes les données qu'on peut vouloir trouver
sur la ligne de commande d'une façon qui soit organisée.
Désolé, j'ai déjÍ beaucoup écrit, je n'ai pas le courage de continuer.
il n'en restait plus bcp,
mais si tu avais encore des choses Í dire et que tu as de nouveau du
courage, ça sera avec plaisir :-))
Faire autrement, outre que ça ne servirait Í rien, rendrait impossible
d'avoir la valeur -- comme paramètre de l'option -a : ce serait donc Í
la fois inutile et nuisible !
Faire autrement, outre que ça ne servirait Í rien, rendrait impossible
d'avoir la valeur -- comme paramètre de l'option -a : ce serait donc Í
la fois inutile et nuisible !
Faire autrement, outre que ça ne servirait Í rien, rendrait impossible
d'avoir la valeur -- comme paramètre de l'option -a : ce serait donc Í
la fois inutile et nuisible !
Le 14/07/2022 18:54, Thomas a écrit :-o -v => -v est l'argument de l'option -o (idem "-o-v")
-o -- c'est pareil ?
Oui, bien sͻr.c'est un cas particulier o͹ -- n'interrompt pas les
options ?
Non, c'est le cas *général* qui est que la forme d'un paramètre d'option
n'a aucune espèce d'influence sur le traitement des options.
C'est juste une chaÍ®ne de caractères qui sera traitée dans un second temps
comme le paramètre du -o.
[...]
sérieusement, tu pratiques ça souvent, de ne pas mettre d'espace pour
tes arguments d'option alors que c'est autorisé ?
Pour ma part, cela dépend. Par exemple je n'ai aucune hésitation pour un
chiffre donnant un niveau de debug (-d5 pour -d 5), dans certaines commandes
je n'hésiterais pas non plus lorsque les paramètres possibles sont des mots-
clés d'une liste connue (-ttcp, -tudp, -ticmp), mais j'hésiterais pour des
noms de fichiers (-f.profile pour -f .profile).
accepter "-odir" comme "-o dir",est-ce que c'est qqch que les usagers utilisent bcp, ça ?
Oui.
Le 14/07/2022 18:54, Thomas a écrit :
>>
>> -o -v => -v est l'argument de l'option -o (idem "-o-v")
>
> -o -- c'est pareil ?
Oui, bien sͻr.
> c'est un cas particulier o͹ -- n'interrompt pas les
> options ?
Non, c'est le cas *général* qui est que la forme d'un paramètre d'option
n'a aucune espèce d'influence sur le traitement des options.
C'est juste une chaÍ®ne de caractères qui sera traitée dans un second temps
comme le paramètre du -o.
> [...]
>
> sérieusement, tu pratiques ça souvent, de ne pas mettre d'espace pour
> tes arguments d'option alors que c'est autorisé ?
Pour ma part, cela dépend. Par exemple je n'ai aucune hésitation pour un
chiffre donnant un niveau de debug (-d5 pour -d 5), dans certaines commandes
je n'hésiterais pas non plus lorsque les paramètres possibles sont des mots-
clés d'une liste connue (-ttcp, -tudp, -ticmp), mais j'hésiterais pour des
noms de fichiers (-f.profile pour -f .profile).
>> accepter "-odir" comme "-o dir",
> est-ce que c'est qqch que les usagers utilisent bcp, ça ?
Oui.
Le 14/07/2022 18:54, Thomas a écrit :-o -v => -v est l'argument de l'option -o (idem "-o-v")
-o -- c'est pareil ?
Oui, bien sͻr.c'est un cas particulier o͹ -- n'interrompt pas les
options ?
Non, c'est le cas *général* qui est que la forme d'un paramètre d'option
n'a aucune espèce d'influence sur le traitement des options.
C'est juste une chaÍ®ne de caractères qui sera traitée dans un second temps
comme le paramètre du -o.
[...]
sérieusement, tu pratiques ça souvent, de ne pas mettre d'espace pour
tes arguments d'option alors que c'est autorisé ?
Pour ma part, cela dépend. Par exemple je n'ai aucune hésitation pour un
chiffre donnant un niveau de debug (-d5 pour -d 5), dans certaines commandes
je n'hésiterais pas non plus lorsque les paramètres possibles sont des mots-
clés d'une liste connue (-ttcp, -tudp, -ticmp), mais j'hésiterais pour des
noms de fichiers (-f.profile pour -f .profile).
accepter "-odir" comme "-o dir",est-ce que c'est qqch que les usagers utilisent bcp, ça ?
Oui.
Le 14/07/2022 20:02, Thomas a écrit :-a param
(peux tu me confirmer pour -a -- si jamais tu réponds avant Alain stp ?)
J'ai déjÍ répondu. Lorsque le programme lit -a dans les options, il lit
le paramètre qui suit tel quel, sans interprétation.
Faire autrement, outre que ça ne servirait Í rien, rendrait impossible
d'avoir la valeur -- comme paramètre de l'option -a : ce serait donc Í
la fois inutile et nuisible !
[...]Ça me rappelle cette anecdote d'un logiciel o͹
le message « press any key to continue » aurait été changé en « press
a key to continue », parce que des utilisateurs ne savaient pas trouver
la touche « any » mais qu'ils savaient trouver la touche « a ».
ça ressemble Í une réaction d'autiste :-)
Peut-être. Attention quand même Í ne pas avoir une vision trop caricaturale
de ce qu'est un autiste.
Par exemple je me suis rendu compte récemment que
j'ai de nombreux traits autistiques, et que c'était déjÍ dans la famille
avant moi.
[...]si jamais ça t'intéresse, voilÍ les liens pertinents :
Page d'accueil du projet :
http://savannah.nongnu.org/projects/rapid/
§
RAPID is the Rapid Ada Portable Interface Design tool.
§
Haha, j'aime bien les acronymes récursifs. ;-)
Il y a peu de chances que j'aie l'occasion d'apprendre et d'utiliser Ada, de
même qu'il y a peu de chances que j'aie besoin de créer des programmes avec
une interface graphique. Cela fait deux raisons qui m'incitent Í penser que
je n'utiliserai pas rapid.
Cela étant dit, tout est toujours possible : il y a un peu plus d'un an,
jamais
je n'aurais imaginé me mettre Í programmer en Python, et pourtant je m'y suis
mis en quelques jours pour un besoin précis.
[...]
Avertissement ou erreur, c'est toi qui décides. Mais tu t'es simplifié le
parsing des options en faisant une seule boucle et sans te poser des
questions, jusqu'au moment o͹ tu as enfin *tous* les éléments en main
pour le message le plus approprié.
ce que ça m'inspire, c'est que cette boucle, si elle doit être la même
partout, elle peut être factorisée ...
Oui, c'est en gros le bout d'algorithme que t'avait donné Alain, et c'est
ce que fait en standard la fonction getopt().getopt() pourrait fournir une structure de données en forme de
map (carte ?), contenant toutes les données qu'on peut vouloir trouver
sur la ligne de commande d'une façon qui soit organisée.
L'argument principal que tu dois donner Í getopt, c'est la liste des
noms d'option (en une seule lettre), avec pour chacun d'eux si cette
option attend ou non un paramètre.
Désolé, j'ai déjÍ beaucoup écrit, je n'ai pas le courage de continuer.
il n'en restait plus bcp,
mais si tu avais encore des choses Í dire et que tu as de nouveau du
courage, ça sera avec plaisir :-))
Bah, en gros tu me demandais mon avis sur une syntaxe moins standard du
style de cvs ou svn. Comme c'est moins standard, je n'ai pas vraiment
d'avis bien tranché dessus. C'est surtout ça qui fait que je manque de
courage pour y réfléchir.
Le 14/07/2022 20:02, Thomas a écrit :
>
>> -a param
>
> (peux tu me confirmer pour -a -- si jamais tu réponds avant Alain stp ?)
J'ai déjÍ répondu. Lorsque le programme lit -a dans les options, il lit
le paramètre qui suit tel quel, sans interprétation.
Faire autrement, outre que ça ne servirait Í rien, rendrait impossible
d'avoir la valeur -- comme paramètre de l'option -a : ce serait donc Í
la fois inutile et nuisible !
> [...]
>
>> Ça me rappelle cette anecdote d'un logiciel o͹
>> le message « press any key to continue » aurait été changé en « press
>> a key to continue », parce que des utilisateurs ne savaient pas trouver
>> la touche « any » mais qu'ils savaient trouver la touche « a ».
>
> ça ressemble Í une réaction d'autiste :-)
Peut-être. Attention quand même Í ne pas avoir une vision trop caricaturale
de ce qu'est un autiste.
Par exemple je me suis rendu compte récemment que
j'ai de nombreux traits autistiques, et que c'était déjÍ dans la famille
avant moi.
> [...]
> si jamais ça t'intéresse, voilÍ les liens pertinents :
>
> Page d'accueil du projet :
> http://savannah.nongnu.org/projects/rapid/
§
RAPID is the Rapid Ada Portable Interface Design tool.
§
Haha, j'aime bien les acronymes récursifs. ;-)
Il y a peu de chances que j'aie l'occasion d'apprendre et d'utiliser Ada, de
même qu'il y a peu de chances que j'aie besoin de créer des programmes avec
une interface graphique. Cela fait deux raisons qui m'incitent Í penser que
je n'utiliserai pas rapid.
Cela étant dit, tout est toujours possible : il y a un peu plus d'un an,
jamais
je n'aurais imaginé me mettre Í programmer en Python, et pourtant je m'y suis
mis en quelques jours pour un besoin précis.
>> [...]
>> Avertissement ou erreur, c'est toi qui décides. Mais tu t'es simplifié le
>> parsing des options en faisant une seule boucle et sans te poser des
>> questions, jusqu'au moment o͹ tu as enfin *tous* les éléments en main
>> pour le message le plus approprié.
>
> ce que ça m'inspire, c'est que cette boucle, si elle doit être la même
> partout, elle peut être factorisée ...
Oui, c'est en gros le bout d'algorithme que t'avait donné Alain, et c'est
ce que fait en standard la fonction getopt().
> getopt() pourrait fournir une structure de données en forme de
> map (carte ?), contenant toutes les données qu'on peut vouloir trouver
> sur la ligne de commande d'une façon qui soit organisée.
L'argument principal que tu dois donner Í getopt, c'est la liste des
noms d'option (en une seule lettre), avec pour chacun d'eux si cette
option attend ou non un paramètre.
>> Désolé, j'ai déjÍ beaucoup écrit, je n'ai pas le courage de continuer.
>
> il n'en restait plus bcp,
> mais si tu avais encore des choses Í dire et que tu as de nouveau du
> courage, ça sera avec plaisir :-))
Bah, en gros tu me demandais mon avis sur une syntaxe moins standard du
style de cvs ou svn. Comme c'est moins standard, je n'ai pas vraiment
d'avis bien tranché dessus. C'est surtout ça qui fait que je manque de
courage pour y réfléchir.
Le 14/07/2022 20:02, Thomas a écrit :-a param
(peux tu me confirmer pour -a -- si jamais tu réponds avant Alain stp ?)
J'ai déjÍ répondu. Lorsque le programme lit -a dans les options, il lit
le paramètre qui suit tel quel, sans interprétation.
Faire autrement, outre que ça ne servirait Í rien, rendrait impossible
d'avoir la valeur -- comme paramètre de l'option -a : ce serait donc Í
la fois inutile et nuisible !
[...]Ça me rappelle cette anecdote d'un logiciel o͹
le message « press any key to continue » aurait été changé en « press
a key to continue », parce que des utilisateurs ne savaient pas trouver
la touche « any » mais qu'ils savaient trouver la touche « a ».
ça ressemble Í une réaction d'autiste :-)
Peut-être. Attention quand même Í ne pas avoir une vision trop caricaturale
de ce qu'est un autiste.
Par exemple je me suis rendu compte récemment que
j'ai de nombreux traits autistiques, et que c'était déjÍ dans la famille
avant moi.
[...]si jamais ça t'intéresse, voilÍ les liens pertinents :
Page d'accueil du projet :
http://savannah.nongnu.org/projects/rapid/
§
RAPID is the Rapid Ada Portable Interface Design tool.
§
Haha, j'aime bien les acronymes récursifs. ;-)
Il y a peu de chances que j'aie l'occasion d'apprendre et d'utiliser Ada, de
même qu'il y a peu de chances que j'aie besoin de créer des programmes avec
une interface graphique. Cela fait deux raisons qui m'incitent Í penser que
je n'utiliserai pas rapid.
Cela étant dit, tout est toujours possible : il y a un peu plus d'un an,
jamais
je n'aurais imaginé me mettre Í programmer en Python, et pourtant je m'y suis
mis en quelques jours pour un besoin précis.
[...]
Avertissement ou erreur, c'est toi qui décides. Mais tu t'es simplifié le
parsing des options en faisant une seule boucle et sans te poser des
questions, jusqu'au moment o͹ tu as enfin *tous* les éléments en main
pour le message le plus approprié.
ce que ça m'inspire, c'est que cette boucle, si elle doit être la même
partout, elle peut être factorisée ...
Oui, c'est en gros le bout d'algorithme que t'avait donné Alain, et c'est
ce que fait en standard la fonction getopt().getopt() pourrait fournir une structure de données en forme de
map (carte ?), contenant toutes les données qu'on peut vouloir trouver
sur la ligne de commande d'une façon qui soit organisée.
L'argument principal que tu dois donner Í getopt, c'est la liste des
noms d'option (en une seule lettre), avec pour chacun d'eux si cette
option attend ou non un paramètre.
Désolé, j'ai déjÍ beaucoup écrit, je n'ai pas le courage de continuer.
il n'en restait plus bcp,
mais si tu avais encore des choses Í dire et que tu as de nouveau du
courage, ça sera avec plaisir :-))
Bah, en gros tu me demandais mon avis sur une syntaxe moins standard du
style de cvs ou svn. Comme c'est moins standard, je n'ai pas vraiment
d'avis bien tranché dessus. C'est surtout ça qui fait que je manque de
courage pour y réfléchir.
Olivier Miakinen , dans le message <tane3v$283q$,
a écrit :OPTIONS
Est une liste d'options dont chacune commence par un tiret, parfois
deux tirets pour les options longues. Chaque option est soit sans
paramètre, soit avec un paramètre unique. Qu'il y ait ou non un
paramètre est propre Í l'option et ne change pas pour cette commande
et cette option. Exemples :
-a
--nom-long
-a param
-aparam--nom-long=param
Ou --nom-long param.
Par ailleurs, je sais que l'on passe automatiquement de la partie OPTIONS
Í la partie ARGUMENTS dès que l'on trouve un mot qui commence par autre
chose qu'un tiret (en dehors des paramètres d'options bien sÍ»r).
Sauf les GNUeries, qui acceptent des options après des arguments. Mais
respectent -- heureusement !
Le reste de tes conseils me semble de tout bon sens.
Olivier Miakinen , dans le message <tane3v$283q$1@cabale.usenet-fr.net>,
a écrit :
> OPTIONS
> Est une liste d'options dont chacune commence par un tiret, parfois
> deux tirets pour les options longues. Chaque option est soit sans
> paramètre, soit avec un paramètre unique. Qu'il y ait ou non un
> paramètre est propre Í l'option et ne change pas pour cette commande
> et cette option. Exemples :
> -a
> --nom-long
> -a param
> -aparam
> --nom-long=param
Ou --nom-long param.
> Par ailleurs, je sais que l'on passe automatiquement de la partie OPTIONS
> Í la partie ARGUMENTS dès que l'on trouve un mot qui commence par autre
> chose qu'un tiret (en dehors des paramètres d'options bien sÍ»r).
Sauf les GNUeries, qui acceptent des options après des arguments. Mais
respectent -- heureusement !
Le reste de tes conseils me semble de tout bon sens.
Olivier Miakinen , dans le message <tane3v$283q$,
a écrit :OPTIONS
Est une liste d'options dont chacune commence par un tiret, parfois
deux tirets pour les options longues. Chaque option est soit sans
paramètre, soit avec un paramètre unique. Qu'il y ait ou non un
paramètre est propre Í l'option et ne change pas pour cette commande
et cette option. Exemples :
-a
--nom-long
-a param
-aparam--nom-long=param
Ou --nom-long param.
Par ailleurs, je sais que l'on passe automatiquement de la partie OPTIONS
Í la partie ARGUMENTS dès que l'on trouve un mot qui commence par autre
chose qu'un tiret (en dehors des paramètres d'options bien sÍ»r).
Sauf les GNUeries, qui acceptent des options après des arguments. Mais
respectent -- heureusement !
Le reste de tes conseils me semble de tout bon sens.
