Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > fr.comp.os.unix > #7958 > unrolled thread

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

Back to article view | Back to fr.comp.os.unix

Contents

  règle pour écrire les "usage: ..." Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-07-09 01:59 +0200
    Re: règle pour écrire les "usage: ..." ST <st@unices.org> - 2022-07-09 04:26 +0000
      Re: règle pour écrire les "usage: ..." Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-07-09 16:02 +0200
        Re: règle pour écrire les "usage: ..." Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2022-07-09 23:21 +0200
          Re: règle pour écrire les "usage: ..." Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-07-11 18:43 +0200
            Re: règle pour écrire les "usage: ..." Olivier Miakinen <om+news@miakinen.net> - 2022-07-11 18:59 +0200
              Re: règle pour écrire les "usage: ..." Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2022-07-11 23:17 +0200
                Re: règle pour écrire les "usage: ..." Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-07-13 03:52 +0200
                  Re: règle pour écrire les "usage: ..." Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2022-07-13 13:45 +0200
                    Re: règle pour écrire les "usage: ..." Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-07-13 16:45 +0200
                      Re: règle pour écrire les "usage: ..." Nicolas George <nicolas$george@salle-s.org> - 2022-07-13 15:24 +0000
                        Re: règle pour écrire les "usage: ..." Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-07-13 18:24 +0200
                          Re: règle pour écrire les "usage: ..." Olivier Miakinen <om+news@miakinen.net> - 2022-07-13 18:51 +0200
                            Re: règle pour écrire les "usage: ..." Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-07-13 21:36 +0200
                              Re: règle pour écrire les "usage: ..." Olivier Miakinen <om+news@miakinen.net> - 2022-07-13 23:40 +0200
                                Re: règle pour écrire les "usage: ..." Nicolas George <nicolas$george@salle-s.org> - 2022-07-13 22:48 +0000
                                  Re: règle pour écrire les "usage: ..." Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-08-09 20:48 +0200
                                    Re: règle pour écrire les "usage: ..." Nicolas George <nicolas$george@salle-s.org> - 2022-08-09 22:17 +0000
                                      Re: règle pour écrire les "usage: ..." Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-08-14 02:14 +0200
                                        Re: règle pour écrire les "usage: ..." Nicolas George <nicolas$george@salle-s.org> - 2022-08-14 08:46 +0000
                                          Re: règle pour écrire les "usage: ..." Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2023-04-19 03:27 +0200
                                Re: règle pour écrire les "usage: ..." Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-07-14 20:02 +0200
                                  Re: règle pour écrire les "usage: ..." Olivier Miakinen <om+news@miakinen.net> - 2022-07-14 20:55 +0200
                                    Re: règle pour écrire les "usage: ..." Marc SCHAEFER <schaefer@alphanet.ch> - 2022-07-14 19:06 +0000
                                    Re: règle pour écrire les "usage: ..." Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-07-31 04:54 +0200
                          Re: règle pour écrire les "usage: ..." Nicolas George <nicolas$george@salle-s.org> - 2022-07-13 17:23 +0000
                      Re: règle pour écrire les "usage: ..." Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2022-07-13 19:15 +0200
                        Re: règle pour écrire les "usage: ..." Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-07-14 18:54 +0200
                          Re: règle pour écrire les "usage: ..." Olivier Miakinen <om+news@miakinen.net> - 2022-07-14 20:33 +0200
                            Re: règle pour écrire les "usage: ..." Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-07-31 03:02 +0200
                  Re: règle pour écrire les "usage: ..." Nicolas George <nicolas$george@salle-s.org> - 2022-07-13 14:10 +0000
              Re: règle pour écrire les "usage: ..." Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-07-11 23:50 +0200
              Re: règle pour écrire les "usage: ..." Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-08-14 03:07 +0200
    Re: règle pour écrire les "usage: ..." Olivier Miakinen <om+news@miakinen.net> - 2022-07-09 07:42 +0200
      Re: règle pour écrire les "usage: ..." Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-07-09 15:38 +0200
        Re: règle pour écrire les "usage: ..." Olivier Miakinen <om+news@miakinen.net> - 2022-07-09 16:54 +0200

Page 2 of 2 — ← Prev page 1 [2]

#8060

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

> Thomas , dans le message <62f83e78$0$9142$426a34cc@news.free.fr>, a
>  écrit :
> >> Évidemment que non.
> > je n'ai pas compris.
> 
> J'ai mal cité, je répondais à :
> 
> >>> --nom-longparam ?

du coup, comme la forme courte de mes options fait 2 lettres 
(pas 1 seule), est-ce que ça veut dire que je ne suis pas tenu de 
prendre en charge "-oddir" pour "-od dir" ?

(pardon si je pose une question déjà répondue, ça fait un moment ...)


> > pourquoi est-ce que ça ne te convenait pas de faire cet échappement ?
> 
> Parce que les noms de fichiers ne sont pas les seuls arguments qui peuvent
> avoir besoin d'être protégés.

ça j'en tiendrai compte au besoin.
(mais a priori, si je veux rajouter des options, j'essaierai de le faire 
dans l'interface graphique plutôt qu'en ligne de commande)

> Parce que même pour les fichiers, faire « cet
> échappement » correctement dépend de la forme du nom.

ah bon ?? dans quels cas ça ne marche pas ? peux tu me donner un exemple 
stp, je ne vois pas du tout.

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

[toc] | [prev] | [next] | [standalone]

#7983

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

> Pour fixer le contexte,

bonne idée :-)

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

ça compte !

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

(peux tu me confirmer pour -a -- si jamais tu réponds avant Alain stp ?)

>        -aparam
>        --nom-long=param

(si je n'arrive pas à faire marcher getopt() je ne programmerai pas ça.)

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

ah oui, c'est une façon de dire plus élégante que la mienne, et 
effectivement ça passe "autrement" :-D

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

j'aime bien l'analogie :-)

> Ç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 :-)



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

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/

une partie de la doc :
http://www.nongnu.org/rapid/

une autre partie de la doc : la documentation Markdown que j'ai faite, 
et qu'on ne trouve pas ailleurs parce que je n'ai pas encore fait de 
version publique officielle :
http://svn.savannah.gnu.org/viewvc/rapid/branches/gtkada-2.24/



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

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.

si je trouve le temps, j'essaierai de le faire,
mais en ADA, alors je donne l'idée tout de suite pour les autres ;-)



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

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

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

[toc] | [prev] | [next] | [standalone]

#7985

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.

> [...]
> 
> 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/

§
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

[toc] | [prev] | [next] | [standalone]

#7986

Olivier Miakinen <om+news@miakinen.net> wrote:
> 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 !

En théorie -a '--' pourrait fonctionner?

[toc] | [prev] | [next] | [standalone]

#7990

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

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

moi aussi j'ai trouvé plus logique de répondre de l'autre coté. ;-)

> 
> 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 !

si on n'en a qu'un seul, on pourrais faire "-a -- --".
mais, tu as raison, si on en a besoin d'un 2eme comme ça, c'est cuit !



> 
> > [...]
> > 
> >> Ç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.

je le suis,
par contre ma remarque est basée bcp plus sur ce que j'ai appris que sur 
mon expérience perso.

tu as raison de dire d'être vigilant sur ce sujet,
par contre je crois que c'est assez souvent une bonne chose de mettre le 
sujet sur la table quand on en a l'occasion, ne serais-ce que pour 
sensibiliser "par force" les ignorants, même si on n'a pas une précision 
"d'horloger suisse"
(à condition que personne ne soit dogmatique, sinon j'imagine que ça 
peut vite fiche les choses par terre).


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

tu aurais éventuellement intérêt à vérifier.
c'est tout à fait optionnel si tu trouves ton environnement confortable 
et ton entourage bienveillant.



> 
> > [...]

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

:-)


perso je considère que c'est pas rigoureusement récursif, parce que le 
"Rapid" désigné par le R est l'adjectif.
mais d'après moi l'auteur a d'autant plus de mérite, par rapport à ceux 
qui sont rigoureusement récursif.

par ex HAC (HAC Ada Compiler) ( https://hacadacompiler.sourceforge.io/ ),
même s'il a probablement aussi voulu faire un jeu de mots avec 
"hacking", pour son acronyme il a pu choisir la 1ere lettre qu'il 
voulait, elle ne lui était pas imposée par son acronyme.


je n'ai encore jamais vu d'acronyme récursif dont l'acronyme ne serait 
pas le 1er mot, du genre :

RADAR = Radio Aberration Detection Acronym RADAR

c'est pas évident : l'initiale de l'acronyme doit obligatoirement 
correspondre à la lettre de la place qu'il occupe.

(bon, je n'arrive pas tellement à être clair, mais je suppose que tu 
arrives quand même à me suivre. :-) )


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

bon, he bien ... pour mon ego, je souhaite que tu t'y mettes. ;-)

... mais pas demain matin, c'est pas possible, c'est pas prêt. :-)



> 
> >> [...]
> >> 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.


je ne suis pas sur que tu aies bien compris,
mais ce qui nous a embrouillé c'est surement :
- qu'en Ada il est autorisé de faire plusieurs fonctions de même nom 
avec des paramètres (y compris le retour) différents,
- alors qu'en C je crois bien que c'est interdit.

je parle d'une fonction getopt() à laquelle on donne les mêmes 
paramètres d'entrée, mais :
- qu'on n'appelle qu'une seule fois,
- au lieu de donner des infos sur 1 switch à la fois,
ça retourne une structure de données contenant toutes les infos sur tous 
les switches.
à nous, ensuite, d'aller piocher dans cette structure de données ce 
qu'on cherche.


à propos, est-ce qu'il y a des cas de figure où on ne donne pas tout le 
temps les mêmes paramètres d'entrée à getopt() ?



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

ok.

alors une condition pour le faire si je me met à getopt(), c'est que 
cette fonction soit compatible avec cet usage.
(mais tu ne sais probablement pas, si tu ne t'en sers pas (?) )



je me rappelle d'une question connexe :

j'ai remarqué que svn, comme make, autorise l'auto-complétion, avec ses 
commandes à lui.

quand c'est pour les fichiers, le shell se débrouille avec le système, 
pas besoin d'interaction avec le programme.

mais là, comment ça se passe ?
est-ce que ça nécessite des fonctions posix, pas forcément portables ?

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

[toc] | [prev] | [next] | [standalone]

#7978

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.

[toc] | [prev] | [next] | [standalone]

#7977

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.

[toc] | [prev] | [next] | [standalone]

#7982

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/

[toc] | [prev] | [next] | [standalone]

#7984

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. Lorsque tu
lis les options, si tu tombes sur -o et que c'est une option avec paramètre,
alors tu te contentes de récupérer ce paramètre avant de passer à l'option
suivante, mais ce paramètre ne *peut pas* être une option. Ça ne peut donc
pas être non plus le délimiteur de fin d'options, et ça ne peut pas non
plus être le premier argument de type gui_file.

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

Quoi qu'il en soit, je trouve qu'il vaut mieux être permissif sur ce point
de la part du programme. Après tout, on écrit le programme une seule fois
alors que, si le programme est utile, on l'appellera un grand nombre de fois.


-- 
Olivier Miakinen

[toc] | [prev] | [next] | [standalone]

#7989

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

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

merci pour l'éclaircissement, c'est programmé en suivant ce principe. :-)


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

merci pour l'éclaircissement là aussi. :-)
je n'avais pas pensé aux autres usages, et du coup je suis d'accord avec 
toi. :-)


Nicolas m'a induit en erreur :

> >> accepter "-odir" comme "-o dir",
> > est-ce que c'est qqch que les usagers utilisent bcp, ça ?
> 
> Oui.

avec des noms de fichiers / répertoires, je trouve ça illisible.

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

[toc] | [prev] | [next] | [standalone]

#7971

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.

[toc] | [prev] | [next] | [standalone]

#7968

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

> Le 11/07/2022 18:43, Thomas répondait à Alain Ketterlin :
> >> 
> >> Personnellement je préfère éviter |, ce qui évite aussi les parenthèses
> >> en général. Par exemple, chez moi la page de man de sort indique
> >> 
> >>        sort [OPTION]... [FILE]...
> >>        sort [OPTION]... --files0-from=F
> > 
> > bonne idée :-)
> > 
> > je préfère ta proposition que celle d'Olivier
> 
> Ça tombe très bien, parce que moi aussi. :-)
> 
> Il se trouve simplement que je n'y avais pas pensé, mais cette méthode me
> semble aussi éminemment préférable

ok :-)


> 
> >> (note le retour de l'étoile, sous la forme [x]...)
> > 
> > perso j'aurais préféré [x...]
> > (sachant que les 2 sont parfaitement équivalents)
> > 
> > en fait, pour l'ambiguité, il est permis d'avoir un minuscule doute :
> 
> Pas vraiment ici.
> 
> > est-ce que
> > x [y] ...
> > équivaut à
> > x ([y] ...)
> > ou à
> > (x [y]) ...
> > ?
> 
> Dans l'exemple donné par Alain il n'est absolument pas question de :
> x [y] ...
> mais de :
> x [y]...
> 
> L'absence d'espace entre le crochet et les trois points ne laisse ÀMHA
> aucun doute sur l'interprétation de cette écriture.

je viens de m'apercevoir qu'au début je n'ai pas mis d'espace,
puis, en voyant qu'il y en avait dans les exemples trouvés sur mon ordi, 
et puisque les arguments multipliés sont séparés par des espaces, j'ai 
trouvé que c'était une bonne chose.
(pas la même signification que "..." dans les phrases, sans espace en 
langue anglaise.)

donc je m'apprête à utiliser "x ...", et "[x ...]" quand j'en aurai 
besoin. est-ce que j'ai tord ?


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

aie !

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

ce que tu demandes est suffisamment clair.

mais ensuite, comment fais-tu pour programmer ça ? ...

> 
> > dans l'erreur j'ai précisé :
> > Unknown or misplaced switch
> >            ^^^^^^^^^
> 
> Cela me semble une brutalité excessive pour l'utilisateur, avec un risque
> qu'il te maudisse jusqu'à la cinquantième génération.

je vais voir ce que je peux faire, mais je ne te promet rien.

je trouve que c'est d'une brutalité déjà suffisante, d'avoir à traiter 
une liste d'arguments de commande qui soit autre chose qu'une simple 
liste de fichiers ! :-)

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

[toc] | [prev] | [next] | [standalone]

#8010

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

> Le 11/07/2022 18:43, Thomas répondait à Alain Ketterlin :
> >> 
> >> Personnellement je préfère éviter |, ce qui évite aussi les parenthèses
> >> en général. Par exemple, chez moi la page de man de sort indique
> >> 
> >>        sort [OPTION]... [FILE]...
> >>        sort [OPTION]... --files0-from=F
> > 
> > bonne idée :-)
> > 
> > je préfère ta proposition que celle d'Olivier
> 
> Ça tombe très bien, parce que moi aussi. :-)
> 
> Il se trouve simplement que je n'y avais pas pensé, mais cette méthode me
> semble aussi éminemment préférable


j'ai ajouté une option, et je vais diviser rapid en 2,
ce qui donnera :

d'un coté :
Usage: ./rapid [-v] [gui_file]

de l'autre coté :
Usage: ./rapid-cli [-v] [-od output_directory] gui_file ...
       ./rapid-cli [-v] -ug gui_file ...


ce que je voudrai peut-être faire plus tard, c'est pouvoir faire les 2 
actions de rapid-cli en même temps.
pour ça je nomme la 1ere en la laissant facultative pour la 
compatibilité :

Usage: ./rapid-cli [-v] [-ga] [-od output_directory] gui_file ...
       ./rapid-cli [-v] -ug gui_file ...

ensuite j'ajoute la possibilité de combiner les 2 :

Usage: ./rapid-cli [-v] [-ga] [-od output_directory] gui_file ...
       ./rapid-cli [-v] -ug gui_file ...
       ./rapid-cli [-v] -ga -ug [-od output_directory] gui_file ...


est-ce que c'est bien de les présenter comme ça ?
ce qui me gêne, c'est que ça ne représente pas un 3eme état différent, 
c'est juste l'union des 2 1ers.

le pb c'est que je ne vois pas comment faire une combinaison de tout ça 
qui soit bien propre.

./rapid-cli [-v] [[-ga] [-ug] | [-ga [-ug]] -od output_directory] 
gui_file ...

il me semble que de cette manière, il est impossible d'avoir à la fois 
-od, -ug, et pas -ga.
mais bon, ça fait un peu usine à gaz ...



PS :
je ne sais pas si c'est utile de faire un msg supplémentaire pour ça,
pour info voilà ce que j'ai codé :
http://svn.savannah.gnu.org/viewvc/rapid/branches/gtkada-2.24/src/app/ada
/rapid_main.adb?view=markup&pathrev=278 ( https://urlpetite.net/?75y )

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

[toc] | [prev] | [next] | [standalone]

#7960

Le 09/07/2022 01:59, Thomas a écrit :
> 
> par ex, si j'écris :
> 
> usage: rapid [-v] (gui_file | -ni [-od dir] gui_file...)
> 
> est-ce que tout le monde comprend, sans ambiguité ?

Voici ce que je comprends, toi seul peut dire si ça  correspond sans
ambiguité à ce que tu voulais dire. Pour moi, les syntaxes possibles
sont les suivantes :

rapid gui_file
rapid -ni gui_files
rapid -ni -od dir gui_files
rapid -v gui_file
rapid -v -ni gui_files
rapid -v -ni -od dir gui_files

... où « gui_file » représente un fichier et un seul, tandis que
« gui_files » représente au moins un fichier, sans limite de nombre.


-- 
Olivier Miakinen

[toc] | [prev] | [next] | [standalone]

#7961

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

> Le 09/07/2022 01:59, Thomas a écrit :
> > 
> > par ex, si j'écris :
> > 
> > usage: rapid [-v] (gui_file | -ni [-od dir] gui_file...)

tiens c'est pas bon, j'aurais du écrire ça :
usage: rapid [-v] ([gui_file] | -ni [-od dir] gui_file...)


> > 
> > est-ce que tout le monde comprend, sans ambiguité ?
> 
> Voici ce que je comprends, toi seul peut dire si ça  correspond sans
> ambiguité à ce que tu voulais dire.

si je te comprend bien, pour toi il n'y a pas d'ambiguité, cad pas de 
"zone floue" ou ce genre de truc ?

> Pour moi, les syntaxes possibles
> sont les suivantes :
> 
> rapid gui_file
> rapid -ni gui_files
> rapid -ni -od dir gui_files
> rapid -v gui_file
> rapid -v -ni gui_files
> rapid -v -ni -od dir gui_files
> 
> ... où « gui_file » représente un fichier et un seul, tandis que
> « gui_files » représente au moins un fichier, sans limite de nombre.

c'est exact :-)

je suppose que tu aurais trouvé qu'il fallait ajouter
rapid
rapid -v

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

[toc] | [prev] | [next] | [standalone]

#7963

Le 09/07/2022 15:38, Thomas a écrit :
> In article <tab4gn$1cmq$1@cabale.usenet-fr.net>,
>  Olivier Miakinen <om+news@miakinen.net> wrote:
> 
>> Le 09/07/2022 01:59, Thomas a écrit :
>> > 
>> > par ex, si j'écris :
>> > 
>> > usage: rapid [-v] (gui_file | -ni [-od dir] gui_file...)
> 
> tiens c'est pas bon, j'aurais du écrire ça :
> usage: rapid [-v] ([gui_file] | -ni [-od dir] gui_file...)

Avoir une option vide parmi un choix d'options non optionnelles ne me
semble pas très clair. Voir plus loin.

...

>> rapid gui_file
>> rapid -ni gui_files
>> rapid -ni -od dir gui_files
>> rapid -v gui_file
>> rapid -v -ni gui_files
>> rapid -v -ni -od dir gui_files
>> 
>> ... où « gui_file » représente un fichier et un seul, tandis que
>> « gui_files » représente au moins un fichier, sans limite de nombre.
> 
> c'est exact :-)
> 
> je suppose que tu aurais trouvé qu'il fallait ajouter
> rapid
> rapid -v

Je te propose la façon suivante, beaucoup plus claire ÀMHA :

usage: rapid [-v] [ gui_file | -ni [-od dir] gui_file... ]


-- 
Olivier Miakinen

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | fr.comp.os.unix

csiph-web