Posté par Marotte ⛧ .
En réponse au journal Args parser pour shell.
Évalué à 4.
Dernière modification le 15 février 2024 à 15:58.
Sympa! Il va falloir que je jette un œil. Bon, je n’aime vraiment pas argparse de Python, et comme j’en écris peu et des trucs simples je finis toujours par faire une gestion (削除) à l’arrache (削除ここまで) ad-hoc mais ça mérite que je regarde.
Ça me rappelle qu’il y a de ça seulement quelques jours je me suis rendu compte que la construction que j’utilisais pour avoir des options longues avec getopts (ou plutôt, des versions longues des options courtes, ce qui n’est pas la même chose) souffrait d’un léger problème dont je ne m’étais pas rendu compte :
for argument in "${@}";doshiftcase"${argument}" in
('--verbose')set -- "${@}"'-v';;('--help')set -- "${@}"'-h';;
... ... ...
... ... ...
(*)set -- "${@}""${argument}"esacdone
à mettre avant le bloc de getopts. On peut aussi le grouper avec le getopts dans une fonction mais ça ne change rien au problème.
Ça fait le job, sauf... et bien quand une valeur passée à une option est identique à l’une des options longues, là ça explose en vol, vu que c’est la valeur qui se retrouve « raccourcie ». Faudrait que je vois si je peux trouver une solution pour ce cas précis. Je pourrais ajouter un ('--') break ;;, ce qui permettrait au moins de pouvoir passer une telle valeur en tant qu’argument simple (ie: un argument pris en tant que tel, qui n’est pas la valeur passé à une option), mais c’est pas vraiment une solution.
Même sans parler de l’implémentation la manière de gérer les options est pas toujours évidente. Par exemple j’aime bien les programmes pour lesquels les options/arguments possibles sont en fonction du premier. Comme pour git par exemple. Il me semble qu’argparse le permet d’ailleurs.
# Un débat loin d’être clos la gestion des arguments
Posté par Marotte ⛧ . En réponse au journal Args parser pour shell. Évalué à 4. Dernière modification le 15 février 2024 à 15:58.
Sympa! Il va falloir que je jette un œil. Bon, je n’aime vraiment pas argparse de Python, et comme j’en écris peu et des trucs simples je finis toujours par faire une gestion
(削除) à l’arrache (削除ここまで)ad-hoc mais ça mérite que je regarde.Ça me rappelle qu’il y a de ça seulement quelques jours je me suis rendu compte que la construction que j’utilisais pour avoir des options longues avec getopts (ou plutôt, des versions longues des options courtes, ce qui n’est pas la même chose) souffrait d’un léger problème dont je ne m’étais pas rendu compte :
à mettre avant le bloc de getopts. On peut aussi le grouper avec le getopts dans une fonction mais ça ne change rien au problème.
Ça fait le job, sauf... et bien quand une valeur passée à une option est identique à l’une des options longues, là ça explose en vol, vu que c’est la valeur qui se retrouve « raccourcie ». Faudrait que je vois si je peux trouver une solution pour ce cas précis. Je pourrais ajouter un
('--') break ;;, ce qui permettrait au moins de pouvoir passer une telle valeur en tant qu’argument simple (ie: un argument pris en tant que tel, qui n’est pas la valeur passé à une option), mais c’est pas vraiment une solution.Même sans parler de l’implémentation la manière de gérer les options est pas toujours évidente. Par exemple j’aime bien les programmes pour lesquels les options/arguments possibles sont en fonction du premier. Comme pour git par exemple. Il me semble qu’argparse le permet d’ailleurs.