Path: ...!weretis.net!feeder8.news.weretis.net!pasdenom.info!nntpfeed.proxad.net!proxad.net!feeder1-1.proxad.net!cleanfeed1-a.proxad.net!nnrp1-1.free.fr!not-for-mail
From: Thomas <fantome.forums.tDeContes@free.fr.invalid>
Newsgroups: fr.comp.os.unix
Mail-Copies-To: nobody
Subject: Re: =?ISO-8859-15?Q?r=E8gle_pour_=E9crire?= les "usage: ..."
References: <62c8c4eb$0$24781$426a74cc@news.free.fr> <tahkuf$6ob$1@cabale.usenet-fr.net> <875yk3xsbg.fsf@universite-de-strasbourg.fr.invalid> <62ce256c$0$22264$426a34cc@news.free.fr> <871qupxml4.fsf@universite-de-strasbourg.fr.invalid> <62ceda82$0$24807$426a34cc@news.free.fr> <62cee3c1$0$22053$426a74cc@news.free.fr> <62cef1d6$0$24817$426a34cc@news.free.fr> <tamt6m$2338$1@cabale.usenet-fr.net> <62cf1ed0$0$9166$426a34cc@news.free.fr> <tane3v$283q$1@cabale.usenet-fr.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
User-Agent: MT-NewsWatcher/3.5.3b3 (Intel Mac OS X)
Date: Thu, 14 Jul 2022 20:02:52 +0200
Lines: 171
Message-ID: <62d05a4c$0$9152$426a74cc@news.free.fr>
Organization: Guest of ProXad - France
NNTP-Posting-Date: 14 Jul 2022 20:02:53 CEST
NNTP-Posting-Host: 91.175.52.121
X-Trace: 1657821773 news-2.free.fr 9152 91.175.52.121:15300
X-Complaints-To: abuse@proxad.net
Bytes: 7870

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/