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 1 of 2  [1] 2  Next page →

#7958 — règle pour écrire les "usage: ..."

bonjour :-)


est-ce qu'on peut trouver qqpart une règle pour écrire les "usage: ..." ?

par ex, je sais que [] indique qqch de facultatif, mais il y a plein 
d'autres choses que je ne connais pas / pas bien.


par ex, si j'écris :

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

est-ce que tout le monde comprend, sans ambiguité ?

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

[toc] | [next] | [standalone]

#7959

On 2022-07-08, Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> bonjour :-)
>
>
> est-ce qu'on peut trouver qqpart une règle pour écrire les "usage: ..." ?
>
> par ex, je sais que [] indique qqch de facultatif, mais il y a plein 
> d'autres choses que je ne connais pas / pas bien.
>
>
> par ex, si j'écris :
>
> usage: rapid [-v] (gui_file | -ni [-od dir] gui_file...)
>
> est-ce que tout le monde comprend, sans ambiguité ?
>

"-v" est optionnel

Le "|" marque est un choix entre ce qui est à gauche et ce qui est à
droite, dans lequel "-od dir" est optionnel.

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

#7962

In article <tab00r$v6d7$1@dont-email.me>, ST <st@unices.org> wrote:

> On 2022-07-08, Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> > bonjour :-)
> >
> >
> > est-ce qu'on peut trouver qqpart une règle pour écrire les "usage: ..." ?
> >
> > par ex, je sais que [] indique qqch de facultatif, mais il y a plein 
> > d'autres choses que je ne connais pas / pas bien.
> >
> >
> > par ex, si j'écris :
> >
> > usage: rapid [-v] (gui_file | -ni [-od dir] gui_file...)
> >
> > est-ce que tout le monde comprend, sans ambiguité ?
> >
> 
> "-v" est optionnel
> 
> Le "|" marque est un choix entre ce qui est à gauche et ce qui est à
> droite, dans lequel "-od dir" est optionnel.

je me posais des questions notamment sur :
- () que je ne me rappelle pas avoir vu (j'ai utilisé ça comme le 
symbole mathématique)
- ... que j'ai déjà vu, mais ça me donne une sensation de non-rigoureux 
(donc je posais la question en même temps, ça coute rien ...)
- je crois qu'on utilise qqfois {}, mais je ne me rappelle plus ce que 
ça veut dire.




en passant, je viens de m'apercevoir qu'avant on avait :

$ ls -z
ls: illegal option -- z
usage: ls [-ABCFGHLOPRSTUWabcdefghiklmnopqrstuwx1] [file ...]
$ mkdir -a
mkdir: illegal option -- a
usage: mkdir [-pv] [-m mode] directory ...


et maintenant :

$ ls -z
ls : option invalide -- 'z'
Saisissez « ls --help » pour plus d'informations.
$ mkdir -a
mkdir : option invalide -- 'a'
Saisissez « mkdir --help » pour plus d'informations.


est-ce que le "usage: ..." serais tombé en désuétude ?

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

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

#7964

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

> In article <tab00r$v6d7$1@dont-email.me>, ST <st@unices.org> wrote:
>
>> On 2022-07-08, Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
>> > bonjour :-)
>> >
>> >
>> > est-ce qu'on peut trouver qqpart une règle pour écrire les "usage: ..." ?
>> >
>> > par ex, je sais que [] indique qqch de facultatif, mais il y a plein 
>> > d'autres choses que je ne connais pas / pas bien.

Pour ma part, je comprendrais tout de suite [], | (avec ou sans
parenthèses autour si c'est simple), et ... pour la répétition.

Je ne crois pas qu'il y ait vraiment un standard. C'est essentiellement
un notation pour des expressions régulières, avec ... qui est plus utile
que * (ce serait + pour les expressions régulières, mais ce n'est pas
une construction primitive). Mais c'est rare qu'on ait besoin de toute la
puissance des expression régulières pour des arguments, donc les
notations sont plus "intuitives".

>> > par ex, si j'écris :
>> >
>> > usage: rapid [-v] (gui_file | -ni [-od dir] gui_file...)
>> >
>> > est-ce que tout le monde comprend, sans ambiguité ?
>> >
>> 
>> "-v" est optionnel
>> 
>> Le "|" marque est un choix entre ce qui est à gauche et ce qui est à
>> droite, dans lequel "-od dir" est optionnel.
>
> je me posais des questions notamment sur :
> - () que je ne me rappelle pas avoir vu (j'ai utilisé ça comme le 
> symbole mathématique)

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

(note le retour de l'étoile, sous la forme [x]...)

> - ... que j'ai déjà vu, mais ça me donne une sensation de non-rigoureux 
> (donc je posais la question en même temps, ça coute rien ...)

Je pense qu'il y a un peu de folklore là-dessous : les grammaires des
langages de programmation sont souvent décrites dans le formalisme BNF
(Backus Naur Form -- ou EBNF quand c'est "extended"), c'est-à-dire avec
des expressions régulières en partie droite. C'est donc souvent *très*
rigoureux.

J'ai le souvenir de manuels SQL qui utilisaient massivement ... (peut
être parce que c'est "visuel"). L'usage dans les synposis de commandes
est sûrement plus ancien, cela dit.

> - je crois qu'on utilise qqfois {}, mais je ne me rappelle plus ce que 
> ça veut dire.

Répétition un nombre explicite (ou un intervalle de nombres) : FILE{3,7}
signifierait "entre 3 et 7 fichiers". C'est comme ça que je le
comprendrais, mais je ne crois pas l'avoir jamais vu utilisé pour des
arguments de commandes.

> en passant, je viens de m'apercevoir qu'avant on avait :
>
> $ ls -z
> ls: illegal option -- z
> usage: ls [-ABCFGHLOPRSTUWabcdefghiklmnopqrstuwx1] [file ...]

Encore une notation différente : ici [] signifie aussi bien "optionnel"
que "n'importe lesquels des caractères de la liste" ; dans le second cas,
le "-" doit être en tête. Cela ne correspond à aucune notation formelle
connue, mais je pense que tout le monde comprend.

Bref, c'est la jungle, mais [], |, et ... sont usuels pour des arguments
de commande.

> et maintenant :
>
> $ ls -z
> ls : option invalide -- 'z'
> Saisissez « ls --help » pour plus d'informations.
> $ mkdir -a
> mkdir : option invalide -- 'a'
> Saisissez « mkdir --help » pour plus d'informations.
>
> est-ce que le "usage: ..." serais tombé en désuétude ?

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.

Pour "ls" il y a tellement d'options (avec certaines uniquement sous
forme longue) qu'un synopsis n'a plus grand sens de toute façon. La
seule question que je me pose en voyant le "usage" ci-dessus est :
pourquoi pas -j ou -z ? Mais le chance que j'y trouve l'option que je
cherche est à peu près nulle.

-- Alain.

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

#7965

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

> Thomas <fantome.forums.tDeContes@free.fr.invalid> writes:
> 
> > In article <tab00r$v6d7$1@dont-email.me>, ST <st@unices.org> wrote:
> >
> >> On 2022-07-08, Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> >> > bonjour :-)
> >> >
> >> >
> >> > est-ce qu'on peut trouver qqpart une règle pour écrire les "usage: ..." ?
> >> >
> >> > par ex, je sais que [] indique qqch de facultatif, mais il y a plein 
> >> > d'autres choses que je ne connais pas / pas bien.
> 
> Pour ma part, je comprendrais tout de suite [], | (avec ou sans
> parenthèses autour si c'est simple), et ... pour la répétition.



> > je me posais des questions notamment sur :
> > - () que je ne me rappelle pas avoir vu (j'ai utilisé ça comme le 
> > symbole mathématique)
> 
> 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, parce que -ni ne désigne 
pas une simple option facultative, mais un mode de fonctionnement très 
différent (GUI/CLI)

(sans ça, la proposition d'Olivier était très bien)

> 
> (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 :
est-ce que
x [y] ...
équivaut à
x ([y] ...)
ou à
(x [y]) ...
?



> > usage: ls [-ABCFGHLOPRSTUWabcdefghiklmnopqrstuwx1] [file ...]
> 
> Encore une notation différente : ici [] signifie aussi bien "optionnel"
> que "n'importe lesquels des caractères de la liste" ; dans le second cas,
> le "-" doit être en tête. Cela ne correspond à aucune notation formelle
> connue, mais je pense que tout le monde comprend.

ça fait longtemps que je connais ça (alors j'ai des réflexes)

cad que, [] signifie tjr "optionnel",
mais ce n'est pas une option d'un seul bloc, mais n'importe quelle 
combinaison des lettres proposées, y compris aucune ou toutes.

(j'avais pas remarqué, mais ce que j'ai écrit pourrais aussi être 
interprété comme ça alors que ça n'est pas ce que je veux dire, pour moi 
c'est bien une option d'un seul bloc)

> 
> Bref, c'est la jungle, mais [], |, et ... sont usuels pour des arguments
> de commande.

merci :-)



> > est-ce que le "usage: ..." serais tombé en désuétude ?
> 
> 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é.

dans l'erreur j'ai précisé :
Unknown or misplaced switch
           ^^^^^^^^^

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

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

#7966

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

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

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

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.

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


-- 
Olivier Miakinen

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

#7967

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. Mais imagine que tu écrives "ls" : difficile d'exiger les
options dans l'ordre alphabétique.

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

    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",
accepter "-vn" comme "-v -n", accepter "-odir" comme "-o dir", 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).

Presque tous les outils standard utilisent ça, je pense (sauf les
commandes avec des options de folie, comme gcc). Les directives Posix
sont là :

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02

Et la GNU libc a ses propres extensions, par exemple pour permettre
"--verbose" etc.

-- Alain.

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

#7969

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/

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

#7970

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.

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

#7972

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/

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

#7974

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.

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

#7975

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/

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

#7976

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

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

#7979

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/

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

#7980

Le 13/07/2022 21:36, Thomas a écrit :
>> 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.

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
     Et lorsque toutes les options courtes sont sur un seul caractère je
     sais que je peux les combiner dans n'importe quel ordre. Exemples :
       ls -lt -r
       ls -r -l -t
       ls -tlr
 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.

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

À mon avis, oui. Ceux qui veulent respecter l'ordre le respecteront
et tout ira bien pour eux, tout comme ceux qui pensent que l'ordre
n'a pas d'importance. Ç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 ».

Pour moi, dans ma représentation implicite, ce qui est dans [OPTIONS] est
par défaut indépendant de l'ordre, alors que ce qui est dans [ARGUMENTS]
est par défaut sensible à l'ordre.

> [...]
>> 
>> 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. Par exemple :
>> 
>> Usage: ./rapid i [-v] gui_file
>>        ./rapid ni [-v] [-od output_directory] gui_file...
> 
> oui, comme dans svn :-)
> intéressant :-)

Je n'avais pas osé parlé de cvs :-)

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.


-- 
Olivier Miakinen

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

#7981

Olivier Miakinen , dans le message <tane3v$283q$1@cabale.usenet-fr.net>,
 a écrit :
> 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.

Clap clap clap.

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

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.

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

#8004

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

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

--nom-longparam ?

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

j'ai pris le parti de faire comme les "GNUeries", parce que je crois que 
c'est ce que fait mon getopt().
je n'ai pas encore tenté de m'en servir, mais ça va venir ...

en attendant, j'ai pris soin de prendre en charge "--", comme ça vous 
n'aurez pas à échapper avec "./". :-)

> 
> Le reste de tes conseils me semble de tout bon sens.

je n'ai plus tout le fil en tête, mais je crois les avoir appliqués au 
mieux :-)

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

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

#8006

Thomas , dans le message <62f2abfc$0$22267$426a34cc@news.free.fr>, a
 écrit :
>> Ou --nom-long param.

Évidemment que non.

> j'ai pris le parti de faire comme les "GNUeries"

Mauvaise idée.

> en attendant, j'ai pris soin de prendre en charge "--", comme ça vous 
> n'aurez pas à échapper avec "./". :-)

Encore heureux !

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

#8007

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

> Thomas , dans le message <62f2abfc$0$22267$426a34cc@news.free.fr>, a
>  écrit :
> >> Ou --nom-long param.
> 
> Évidemment que non.

je n'ai pas compris.

> 
> > j'ai pris le parti de faire comme les "GNUeries"
> 
> Mauvaise idée.

pourquoi ?

ça me semble mieux de me mettre au niveau de mon getopt() tout de suite, 
plutôt que de baisser en fonctionnalités au moment où j'y passe.

> 
> > en attendant, j'ai pris soin de prendre en charge "--", comme ça vous 
> > n'aurez pas à échapper avec "./". :-)
> 
> Encore heureux !

pourquoi est-ce que ça ne te convenait pas de faire cet échappement ?

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

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

#8011

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 ?

>> > j'ai pris le parti de faire comme les "GNUeries"
>> Mauvaise idée.
> pourquoi ?

Parce que le comportement des GNUeries est un premier pas vers les machins
automagiques qui essaient de deviner ce que l'utilisateur veut et se
trompent plus souvent qu'ils n'aident.

> ça me semble mieux de me mettre au niveau de mon getopt() tout de suite, 
> plutôt que de baisser en fonctionnalités au moment où j'y passe.

Mais mets-le au niveau des comportement sains, pas des GNUeries.

> 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. Parce que même pour les fichiers, faire « cet
échappement » correctement dépend de la forme du nom.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web