Path: ...!news.mixmin.net!proxad.net!feeder1-2.proxad.net!usenet-fr.net!.POSTED!not-for-mail
From: Olivier Miakinen <om+news@miakinen.net>
Newsgroups: fr.comp.os.unix
Subject: =?UTF-8?Q?Re:_r=c3=a8gle_pour_=c3=a9crire_les_=22usage:_...=22?=
Date: Wed, 13 Jul 2022 18:51:34 +0200
Organization: There's no cabale
Lines: 68
Message-ID: <tamt6m$2338$1@cabale.usenet-fr.net>
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>
NNTP-Posting-Host: 220.12.205.77.rev.sfr.net
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
X-Trace: cabale.usenet-fr.net 1657731094 68712 77.205.12.220 (13 Jul 2022 16:51:34 GMT)
X-Complaints-To: abuse@usenet-fr.net
NNTP-Posting-Date: Wed, 13 Jul 2022 16:51:34 +0000 (UTC)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Firefox/52.0 SeaMonkey/2.49.4
In-Reply-To: <62cef1d6$0$24817$426a34cc@news.free.fr>
Bytes: 3763

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