Gestion des options / switch d'un executable

Salut les amis !

J'espère être au bon endroit pour poser ma question et que je vais réussir à être clair...

Lorsque vous créer un script ou un executable qui sera lancé en ligne de commande avec des options / switchs style :

mon_exe.exe filename.ext /A /B /C /D /E

Comment gérez vous les différents cas de traitements de ces options qui parfois peuvent carrément être incompatibles ou mises dans le désordre?

En effet certains vont lancer l'appli de cette façon :

mon_exe.exe filename.ext /D /A

D'autre de celle manière là :

mon_exe.exe filename.ext /A /D

Ou encore :

mon_exe.exe filename.ext /A /B => avec /A et /B incompatibles

Comment gérez vous tous ces cas? je suppose qu'il existe quelque part un algo simple qui répond à ma question, mais quel est il ?

Il n'y a pas de méthode magique.
Si pour toi, l'ordre des options n'a pas d'importance, tu peux simplement déclarer une variable par option acceptée et les initialiser à 0. Puis parcourir toutes les options données à ton programmes et mettre la variable correspondant à 1.

Une fois que tu as la liste de toutes les options qui ont été données à ton programme, tu n'as plus qu'à vérifier que des options incompatibles n'ont pas été données. Là, pas de méthode magique, il faut que tu liste tous les cas d'options incompatibles. Et si tu trouve que la combinaison d'options données est incohérente : message d'erreur et arrêt du programme.

J'ai toujours eu ce problème. Toujours. À chaque fois que j'écris un petit programme/script, je me retrouve à devoir choisir entre passer 2h à gérer les arguments de manière user-friendly ou faire un truc basique quitte à devoir modifier selon le besoin.

Et moi qui code sous linux, je m'étonne toujours de ne pas avoir trouvé d'outil déjà fait qui permette une gestion intelligente des arguments. Il faut réinventer la roue à chaque fois !

Une alternative : lorsque je le peux et lorsque c'est pertinent, je code en OCaml. Il y a un module tout fait (un genre de stl) qui gère ça de manière vraiment adéquate. Je me suis déjà retrouvé à coder l'interface en ligne de commande en OCaml et le cœur du programme dans un autre langage.

On peut toujours décrire la grammaire sous forme BNF et code un verificateur. Mais ca me semble un peu lourd.

Pour ma part, je préfère définir les caractéristiques de chaque argument et les vérifier un par un.

Argument {
  alias = "lettre ou mot"
  withArgument = yes/no
  mandatory = yes/no
  requires = { list of other Argument }
  forbids = { list of other Argument }
}

C'est vrai qu'il y a aussi les lib à la getopt.
Ça simplifie un peu le parsing, mais je ne connais aucune lib qui soit capable de gérer l'exclusion mutuelle des options.

C'est un truc à coder ça. Le soucis c'est que c'est extrêmement langage-dépendant.

Citation:

---

Envoyé par prgasp77

Et moi qui code sous linux, je m'étonne toujours de ne pas avoir trouvé d'outil déjà fait qui permette une gestion intelligente des arguments. Il faut réinventer la roue à chaque fois !

---

???

Prends n'impote quelle distrib, et regarde les main ..

Ah.. C'est du C.. :aie: :mrgreen:

Mais c'est pas compliqué.

Tu fais une fois, et tu copies/colles..

Faire un programme avec 12 options me prend environ 2 minutes.. pas 2h !!!

Tu as, en première ligne du main

Code:

---

1 2 3 4 5

if ( ! GetOptions ( argc, argc, &structparams ) ) { Usage(); return 1; }

---

Et le GetOptions est simplement

Code:

---

1 2 3 4 5 6 7 8

for ( i = 0 ; i < argc ; i++ ) { if ( strcasecmp ( argv[i], "-i" ) == 0 ) { ... } ... }

---

C'est un peu plus complexe que ça ; il y a les options avec argument, avec argument optionnel, et parfois les arguments un peu complexes (qui doivent avoir leur syntaxe, etc) ; il y a les options qui vont toujours ensembles, et d'autres qui s'excluent mutuellement… Donc à chaque fois il faut coder un parseur d'option pour son programme, et au programme prochain il faut pratiquement tout refaire ; on ne prend jamais la peine de faire une fois pour toute une solution générale. Et oui, il faut pas 2h ; il m'arrive d'user et d'abuser de l'hyperbole.


Edit −−−
J'ai épluché le code source de ls, extrait de coreutils 5.0. En tout, il faut environ 1000 lignes juste pour le parsing des options. Il y a 58 options possibles pour ls. Soit en moyenne 17 lignes de code par options. Et je pense, vu la beauté du code de coreutils (voyez vous même, à part l'indentation pourrie c'est magnifique), je pense que c'est un minimum ; moins on a d'options, moins on a tendance à faire du code générique, et plus il faut de ligne/option. C'est une estimation très grossière, mais ça donne un ordre d'idée à ce qu'il faut faire pour bien gérer les options.

Avec le parseur d'OCaml (qui est un langage haut niveau, la comparaison est difficile), de mémoire il ne me faut pas plus de 3-4 lignes / option (y compris des options complexes) + ~10 lignes.

Honnêtement, ça ne jamais posé un problème...

Je sais dans quels progs j'ai utilisé des arguments à option, je copie/colle..

Quant aux mutuellement exclusifs d'une part il n'y en a pas des tonnes, et à celles qui vont toujours ensemble, c'est pareil...

Franchement..

Et ls (comme gcc) est quand même un des progs ayant le plus d'options..

Honnêtement, c'est (de très très très très très très loin) pas un pbe... Si ???

Non non non, c'est pas un problème. Mais l'intérêt de la programmation, c'est de ne jamais avoir à faire deux fois la même chose, non ?