Path: ...!news.mixmin.net!proxad.net!feeder1-2.proxad.net!usenet-fr.net!.POSTED!not-for-mail From: Olivier Miakinen 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: References: <62c8c4eb$0$24781$426a74cc@news.free.fr> <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