getopt-like - unified way of parsing builtins arguments

[VannTen]

Repensant a la discussion d'hier, j'avais deja code quelque chose comme ca pour ls, et je l'ai ensuite reutilise et ameliore pour mon minishell :
L'interface
La def

L'interface comprend l'initialisation d'une struct synopsis (qui se fait en deux functions parce que la norme.
Il faut lui fournir :

• un tableau de char des options sans parametres
• un tableau de pointeurs sur fonctions dans le meme ordre correspondant a ces parametres.

Et de meme, separement, pour les options avec parametres.
Le parameters void dans les pointeurs sur fonction est au choix de l'application, ca peut etre un tableau de boolean, une structure, ou autre.
Les autres fonctions d'initialisation fournisse un validateur (qui prend le retour des des pointeurs sur fonction et renvoie TRUE sur un resultat valide, FALSE sur un resultat invalide, et une fonction qui print l'usage, qui sera appellé le cas échéant.

Exemples d'usages :

• env
• cd

Pour l'instant, ca ne gere pas les arguments au format long.

[maoux]

j'ai fait un getopt à ma sauce assez simple sur la branche ft_getopt il fonctionne et normalement il est à la norme.
il prend un const char **argv liste des arguments classiques, un const char *sample, toutes les options possibles et un int *error qu'il set à 0 par défaut , à 1 pour une erreur d'allocation, et 2 pour une erreur d'option (usage).
elle renvoie NULL en cas d'erreur, free tout.
Sinon elle renvoie une string contenant toute les options (doublons supprimés) , à free ultérieurement dans le programme.
c'est testé ! :)
(test effectué:
./a.out -aAf1 -l azea toto
./a.out -l -l -l -- -l
./a.out
./a.out toto
./a.out toto -l
./a.out -l toto
./a.out -l -llll
./a.out -ddsfdfsfqzaerlkrg -dsfffsfssfgdgnnrtefd
etc etc )

[VannTen]

Est-ce que tu gères les options qui prennent un paramètres ?
Du genre env -u KEY ?.
Si je saisis bien on a une string avec les options specifie, mais il faut encore appliquer leurs effet ensuite ?

[maoux]

j'y réflechi mais le problème c'est comment savoir si on est dans le cas d'une telle option ou non, à mon avis si on en a des comme ça , faudrait faire un truc plus compliqué ou laissé le builtin se charger de parser ses options qui lui sont propre et utiliser getopt pour des choses plus simples

[VannTen]

Bah ce que je fais dans ma methode c'est de separer les options entre sans param/avec param et d'avoir un applicateur par fonction, qui va update un void * qui est fourni par l'appelant (Et qui du coup peut etre ce que veut l'utilisateur de l'interface, une structure, un tableau de boolean, etc.
Par exemple les options d'env sont geres comme ca :
env options
Par ailleurs ca permet d'appliquer les options dans l'ordre :
env -u KEY -v -u KEY42 par exemple, sera verbose pour le unset de KEY42, mais pas pour celui de KEY

laissé le builtin se charger de parser ses options qui lui sont propre et utiliser getopt pour des choses plus simples

IHMO tout l'interet de deleguer le parsing des options a une fonction dedié c'est de se simplifier la vie pour l'implementation des builtins (la partie qui fait le boulot du builtin proprement dit se contente de prendre un etat des options et de faire avec).