Si getopt avait une option pour lui dire « les options que tu ne
connais pas, mets-les dans un coin mais ne lève pas d'erreur »
Si getopt avait une option pour lui dire « les options que tu ne
connais pas, mets-les dans un coin mais ne lève pas d'erreur »
Si getopt avait une option pour lui dire « les options que tu ne
connais pas, mets-les dans un coin mais ne lève pas d'erreur »
Si getopt avait une option pour lui dire « les options que tu ne
connais pas, mets-les dans un coin mais ne lève pas d'erreur »
info getopt :
If 'getopt' finds an option character in ARGV that was not included
in OPTIONS, or a missing option argument, it returns '?' and sets
the external variable 'optopt' to the actual option character. If
the first character of OPTIONS is a colon (':'), then 'getopt'
returns ':' instead of '?' to indicate a missing option argument.
In addition, if the external variable 'opterr' is nonzero (which is
the default), 'getopt' prints an error message.
En plus standard :
<http://pubs.opengroup.org/onlinepubs/009695399/utilities/getopts.html>
| If an option character not contained in the optstring operand is found
| where an option character is expected, the shell variable specified by
| name shall be set to the question-mark ( '?' ) character. In this
| case, if the first character in optstring is a colon ( ':' ), the
| shell variable OPTARG shall be set to the option character found, but
| no output shall be written to standard error
Après, je ne suis pas sûr que ça suffise car tu passes aussi des
arguments à tes options.
Deux autres pistes :
1) script.sh --common1 c1 --common2 c2 -- --foo --bar remaining_args
2) passer les arguments communs via des variables d'environements
Si getopt avait une option pour lui dire « les options que tu ne
connais pas, mets-les dans un coin mais ne lève pas d'erreur »
info getopt :
If 'getopt' finds an option character in ARGV that was not included
in OPTIONS, or a missing option argument, it returns '?' and sets
the external variable 'optopt' to the actual option character. If
the first character of OPTIONS is a colon (':'), then 'getopt'
returns ':' instead of '?' to indicate a missing option argument.
In addition, if the external variable 'opterr' is nonzero (which is
the default), 'getopt' prints an error message.
En plus standard :
<http://pubs.opengroup.org/onlinepubs/009695399/utilities/getopts.html>
| If an option character not contained in the optstring operand is found
| where an option character is expected, the shell variable specified by
| name shall be set to the question-mark ( '?' ) character. In this
| case, if the first character in optstring is a colon ( ':' ), the
| shell variable OPTARG shall be set to the option character found, but
| no output shall be written to standard error
Après, je ne suis pas sûr que ça suffise car tu passes aussi des
arguments à tes options.
Deux autres pistes :
1) script.sh --common1 c1 --common2 c2 -- --foo --bar remaining_args
2) passer les arguments communs via des variables d'environements
Si getopt avait une option pour lui dire « les options que tu ne
connais pas, mets-les dans un coin mais ne lève pas d'erreur »
info getopt :
If 'getopt' finds an option character in ARGV that was not included
in OPTIONS, or a missing option argument, it returns '?' and sets
the external variable 'optopt' to the actual option character. If
the first character of OPTIONS is a colon (':'), then 'getopt'
returns ':' instead of '?' to indicate a missing option argument.
In addition, if the external variable 'opterr' is nonzero (which is
the default), 'getopt' prints an error message.
En plus standard :
<http://pubs.opengroup.org/onlinepubs/009695399/utilities/getopts.html>
| If an option character not contained in the optstring operand is found
| where an option character is expected, the shell variable specified by
| name shall be set to the question-mark ( '?' ) character. In this
| case, if the first character in optstring is a colon ( ':' ), the
| shell variable OPTARG shall be set to the option character found, but
| no output shall be written to standard error
Après, je ne suis pas sûr que ça suffise car tu passes aussi des
arguments à tes options.
Deux autres pistes :
1) script.sh --common1 c1 --common2 c2 -- --foo --bar remaining_args
2) passer les arguments communs via des variables d'environements
Si getopt avait une option pour lui dire « les options que tu ne
connais pas, mets-les dans un coin mais ne lève pas d'erreur »
info getopt :
If 'getopt' finds an option character in ARGV that was not included
in OPTIONS, or a missing option argument, it returns '?' and sets
the external variable 'optopt' to the actual option character. If
the first character of OPTIONS is a colon (':'), then 'getopt'
returns ':' instead of '?' to indicate a missing option argument.
In addition, if the external variable 'opterr' is nonzero (which is
the default), 'getopt' prints an error message.
Alors là, je n'ai vraiment pas compris la citation ci-dessus.
Ah, j'ai mis un peu de temps avant de voir que tu parlais de
getopts (avec s). On est d'accord qu'avec getopts, il n'est pas
possible de définir des options longues ? C'est dommage je trouve.
Deux autres pistes :
1) script.sh --common1 c1 --common2 c2 -- --foo --bar remaining_args
Ah oui, c'est une possibilité. Il y a le côté esthétique qui
me gêne un peu.2) passer les arguments communs via des variables d'environements
Mettre des variables d'environnement n'est-il pas un peu consommateur
de mémoire ? En effet, je ne l'avais pas précisé mais le contexte est
un peu spécifique. Tous ces scripts sont des plugins (ou checks) au sens
nagios qui seront lancés par un logiciel de supervision. Tout ça pour dire
que les scripts seront lancés très fréquemment par le système (ça peut
monter à ~ 10 exécutions de scripts par seconde). Utiliser des variables
d'environnement ne va-t-il pas demander davantage de ressources au
système ? Il m'a semblé avoir entendu dire ça mais je me trompe peut-être.
Si getopt avait une option pour lui dire « les options que tu ne
connais pas, mets-les dans un coin mais ne lève pas d'erreur »
info getopt :
If 'getopt' finds an option character in ARGV that was not included
in OPTIONS, or a missing option argument, it returns '?' and sets
the external variable 'optopt' to the actual option character. If
the first character of OPTIONS is a colon (':'), then 'getopt'
returns ':' instead of '?' to indicate a missing option argument.
In addition, if the external variable 'opterr' is nonzero (which is
the default), 'getopt' prints an error message.
Alors là, je n'ai vraiment pas compris la citation ci-dessus.
Ah, j'ai mis un peu de temps avant de voir que tu parlais de
getopts (avec s). On est d'accord qu'avec getopts, il n'est pas
possible de définir des options longues ? C'est dommage je trouve.
Deux autres pistes :
1) script.sh --common1 c1 --common2 c2 -- --foo --bar remaining_args
Ah oui, c'est une possibilité. Il y a le côté esthétique qui
me gêne un peu.
2) passer les arguments communs via des variables d'environements
Mettre des variables d'environnement n'est-il pas un peu consommateur
de mémoire ? En effet, je ne l'avais pas précisé mais le contexte est
un peu spécifique. Tous ces scripts sont des plugins (ou checks) au sens
nagios qui seront lancés par un logiciel de supervision. Tout ça pour dire
que les scripts seront lancés très fréquemment par le système (ça peut
monter à ~ 10 exécutions de scripts par seconde). Utiliser des variables
d'environnement ne va-t-il pas demander davantage de ressources au
système ? Il m'a semblé avoir entendu dire ça mais je me trompe peut-être.
Si getopt avait une option pour lui dire « les options que tu ne
connais pas, mets-les dans un coin mais ne lève pas d'erreur »
info getopt :
If 'getopt' finds an option character in ARGV that was not included
in OPTIONS, or a missing option argument, it returns '?' and sets
the external variable 'optopt' to the actual option character. If
the first character of OPTIONS is a colon (':'), then 'getopt'
returns ':' instead of '?' to indicate a missing option argument.
In addition, if the external variable 'opterr' is nonzero (which is
the default), 'getopt' prints an error message.
Alors là, je n'ai vraiment pas compris la citation ci-dessus.
Ah, j'ai mis un peu de temps avant de voir que tu parlais de
getopts (avec s). On est d'accord qu'avec getopts, il n'est pas
possible de définir des options longues ? C'est dommage je trouve.
Deux autres pistes :
1) script.sh --common1 c1 --common2 c2 -- --foo --bar remaining_args
Ah oui, c'est une possibilité. Il y a le côté esthétique qui
me gêne un peu.2) passer les arguments communs via des variables d'environements
Mettre des variables d'environnement n'est-il pas un peu consommateur
de mémoire ? En effet, je ne l'avais pas précisé mais le contexte est
un peu spécifique. Tous ces scripts sont des plugins (ou checks) au sens
nagios qui seront lancés par un logiciel de supervision. Tout ça pour dire
que les scripts seront lancés très fréquemment par le système (ça peut
monter à ~ 10 exécutions de scripts par seconde). Utiliser des variables
d'environnement ne va-t-il pas demander davantage de ressources au
système ? Il m'a semblé avoir entendu dire ça mais je me trompe peut-être.
Soit dit en passant, par rapport à la commande getopt, quelqu'un
peut-il m'expliquer pourquoi j'ai ceci (sur une Wheezy à jour) :
$ getopt -o 'h' -l 'common1:,common2:' -n test.sh -- --common1¡ --common¢
--common1 'a1' --common1 'a2' --
J'indique via -l que j'accepte les option --common1 et --common2.
Mais je fournis l'option --common1 (ok) et l'option --common qui elle
n'est pas censée être autorisée. Je m'attendais à ce que la commande
m'affiche un message d'erreur me disant que l'option --common n'est
pas acceptée. Pourtant ça passe et en plus la commande inflige à
--common1 la valeur 'a2' alors que j'avais indiqué 'a1" comme valeur.
En revanche j'ai bien :
$ getopt -o 'h' -l 'common1:,common2:' -n test.sh -- --common1¡ --common3¢
test.sh : option non reconnue « --common3¢ » ^^^
--common1 'a1' --
Je ne vois pas pourquoi quand j'indique l'option --common3 j'ai
bien un message d'erreur alors que je n'en ai pas pour --common.
Pour moi, les deux commandes ci-dessus devraient renvoyer une
erreur, non ?
Soit dit en passant, par rapport à la commande getopt, quelqu'un
peut-il m'expliquer pourquoi j'ai ceci (sur une Wheezy à jour) :
$ getopt -o 'h' -l 'common1:,common2:' -n test.sh -- --common1¡ --common¢
--common1 'a1' --common1 'a2' --
J'indique via -l que j'accepte les option --common1 et --common2.
Mais je fournis l'option --common1 (ok) et l'option --common qui elle
n'est pas censée être autorisée. Je m'attendais à ce que la commande
m'affiche un message d'erreur me disant que l'option --common n'est
pas acceptée. Pourtant ça passe et en plus la commande inflige à
--common1 la valeur 'a2' alors que j'avais indiqué 'a1" comme valeur.
En revanche j'ai bien :
$ getopt -o 'h' -l 'common1:,common2:' -n test.sh -- --common1¡ --common3¢
test.sh : option non reconnue « --common3¢ » ^^^
--common1 'a1' --
Je ne vois pas pourquoi quand j'indique l'option --common3 j'ai
bien un message d'erreur alors que je n'en ai pas pour --common.
Pour moi, les deux commandes ci-dessus devraient renvoyer une
erreur, non ?
Soit dit en passant, par rapport à la commande getopt, quelqu'un
peut-il m'expliquer pourquoi j'ai ceci (sur une Wheezy à jour) :
$ getopt -o 'h' -l 'common1:,common2:' -n test.sh -- --common1¡ --common¢
--common1 'a1' --common1 'a2' --
J'indique via -l que j'accepte les option --common1 et --common2.
Mais je fournis l'option --common1 (ok) et l'option --common qui elle
n'est pas censée être autorisée. Je m'attendais à ce que la commande
m'affiche un message d'erreur me disant que l'option --common n'est
pas acceptée. Pourtant ça passe et en plus la commande inflige à
--common1 la valeur 'a2' alors que j'avais indiqué 'a1" comme valeur.
En revanche j'ai bien :
$ getopt -o 'h' -l 'common1:,common2:' -n test.sh -- --common1¡ --common3¢
test.sh : option non reconnue « --common3¢ » ^^^
--common1 'a1' --
Je ne vois pas pourquoi quand j'indique l'option --common3 j'ai
bien un message d'erreur alors que je n'en ai pas pour --common.
Pour moi, les deux commandes ci-dessus devraient renvoyer une
erreur, non ?
Je pense que getopt reconnais les raccourcis : si il voit une option qui
correspond au début des options autorisées, il la substitue, essaye avec
« --cºr », il te donnera « --common1 'bar' ». Par contre common3 n'est
pas une option légale.
Je pense que getopt reconnais les raccourcis : si il voit une option qui
correspond au début des options autorisées, il la substitue, essaye avec
« --cºr », il te donnera « --common1 'bar' ». Par contre common3 n'est
pas une option légale.
Je pense que getopt reconnais les raccourcis : si il voit une option qui
correspond au début des options autorisées, il la substitue, essaye avec
« --cºr », il te donnera « --common1 'bar' ». Par contre common3 n'est
pas une option légale.
info getopt :
If 'getopt' finds an option character in ARGV that was not included
in OPTIONS, or a missing option argument, it returns '?' and sets
the external variable 'optopt' to the actual option character. If
the first character of OPTIONS is a colon (':'), then 'getopt'
returns ':' instead of '?' to indicate a missing option argument.
In addition, if the external variable 'opterr' is nonzero (which is
the default), 'getopt' prints an error message.
Alors là, je n'ai vraiment pas compris la citation ci-dessus.
Ne t'inquiète pas, c'est normal. ;-)
C'est la documentation de getopt(3) et non getopt(1)...
Ah, j'ai mis un peu de temps avant de voir que tu parlais de
getopts (avec s). On est d'accord qu'avec getopts, il n'est pas
possible de définir des options longues ? C'est dommage je trouve.
Non. Mais d'un autre coté c'est standard et intégré dans le shell.
2) passer les arguments communs via des variables d'environements
Mettre des variables d'environnement n'est-il pas un peu consommateur
de mémoire ? En effet, je ne l'avais pas précisé mais le contexte est
un peu spécifique. Tous ces scripts sont des plugins (ou checks) au sens
nagios qui seront lancés par un logiciel de supervision. Tout ça pour dire
que les scripts seront lancés très fréquemment par le système (ça peut
monter à ~ 10 exécutions de scripts par seconde). Utiliser des variables
d'environnement ne va-t-il pas demander davantage de ressources au
système ? Il m'a semblé avoir entendu dire ça mais je me trompe peut-être.
Je ne vois pas en quoi ça consommerait de la mémoire,
COMMON1=foo va
utiliser quelque octets mais je ne pense pas que tu sois limité à ce
point. Si tu fait un « env », tu verras que tu en utilises déjà pas mal.
À mon avis, c'est même la plus économe de toutes les solutions
proposées.
info getopt :
If 'getopt' finds an option character in ARGV that was not included
in OPTIONS, or a missing option argument, it returns '?' and sets
the external variable 'optopt' to the actual option character. If
the first character of OPTIONS is a colon (':'), then 'getopt'
returns ':' instead of '?' to indicate a missing option argument.
In addition, if the external variable 'opterr' is nonzero (which is
the default), 'getopt' prints an error message.
Alors là, je n'ai vraiment pas compris la citation ci-dessus.
Ne t'inquiète pas, c'est normal. ;-)
C'est la documentation de getopt(3) et non getopt(1)...
Ah, j'ai mis un peu de temps avant de voir que tu parlais de
getopts (avec s). On est d'accord qu'avec getopts, il n'est pas
possible de définir des options longues ? C'est dommage je trouve.
Non. Mais d'un autre coté c'est standard et intégré dans le shell.
2) passer les arguments communs via des variables d'environements
Mettre des variables d'environnement n'est-il pas un peu consommateur
de mémoire ? En effet, je ne l'avais pas précisé mais le contexte est
un peu spécifique. Tous ces scripts sont des plugins (ou checks) au sens
nagios qui seront lancés par un logiciel de supervision. Tout ça pour dire
que les scripts seront lancés très fréquemment par le système (ça peut
monter à ~ 10 exécutions de scripts par seconde). Utiliser des variables
d'environnement ne va-t-il pas demander davantage de ressources au
système ? Il m'a semblé avoir entendu dire ça mais je me trompe peut-être.
Je ne vois pas en quoi ça consommerait de la mémoire,
COMMON1=foo va
utiliser quelque octets mais je ne pense pas que tu sois limité à ce
point. Si tu fait un « env », tu verras que tu en utilises déjà pas mal.
À mon avis, c'est même la plus économe de toutes les solutions
proposées.
info getopt :
If 'getopt' finds an option character in ARGV that was not included
in OPTIONS, or a missing option argument, it returns '?' and sets
the external variable 'optopt' to the actual option character. If
the first character of OPTIONS is a colon (':'), then 'getopt'
returns ':' instead of '?' to indicate a missing option argument.
In addition, if the external variable 'opterr' is nonzero (which is
the default), 'getopt' prints an error message.
Alors là, je n'ai vraiment pas compris la citation ci-dessus.
Ne t'inquiète pas, c'est normal. ;-)
C'est la documentation de getopt(3) et non getopt(1)...
Ah, j'ai mis un peu de temps avant de voir que tu parlais de
getopts (avec s). On est d'accord qu'avec getopts, il n'est pas
possible de définir des options longues ? C'est dommage je trouve.
Non. Mais d'un autre coté c'est standard et intégré dans le shell.
2) passer les arguments communs via des variables d'environements
Mettre des variables d'environnement n'est-il pas un peu consommateur
de mémoire ? En effet, je ne l'avais pas précisé mais le contexte est
un peu spécifique. Tous ces scripts sont des plugins (ou checks) au sens
nagios qui seront lancés par un logiciel de supervision. Tout ça pour dire
que les scripts seront lancés très fréquemment par le système (ça peut
monter à ~ 10 exécutions de scripts par seconde). Utiliser des variables
d'environnement ne va-t-il pas demander davantage de ressources au
système ? Il m'a semblé avoir entendu dire ça mais je me trompe peut-être.
Je ne vois pas en quoi ça consommerait de la mémoire,
COMMON1=foo va
utiliser quelque octets mais je ne pense pas que tu sois limité à ce
point. Si tu fait un « env », tu verras que tu en utilises déjà pas mal.
À mon avis, c'est même la plus économe de toutes les solutions
proposées.
Bon, j'ai quand même tenté un ultime essai (voir ci-dessous) qui
semble faire ce que je souhaite mais c'est peut-être un peu tordu.
Qu'en pensez-vous ? Est-ce que ça répond bien au problème ?
Bon, j'ai quand même tenté un ultime essai (voir ci-dessous) qui
semble faire ce que je souhaite mais c'est peut-être un peu tordu.
Qu'en pensez-vous ? Est-ce que ça répond bien au problème ?
Bon, j'ai quand même tenté un ultime essai (voir ci-dessous) qui
semble faire ce que je souhaite mais c'est peut-être un peu tordu.
Qu'en pensez-vous ? Est-ce que ça répond bien au problème ?
Bon, j'ai quand même tenté un ultime essai (voir ci-dessous) qui
semble faire ce que je souhaite mais c'est peut-être un peu tordu.
Qu'en pensez-vous ? Est-ce que ça répond bien au problème ?
À vrai dire, je ne sais pas si ça répond au problème car je n'ai pas en
tête d'exemple équivalent à ce que tu souhaites faire. Peux-tu donner un
exemple concret de besoin d'avoir les mêmes options pour plusieurs
programmes ? Quel genre de tâches font ces options ?
Il y a peut-être plus simple à faire qu'une usine à gaz. Dans le cas
contraire, il existe sans doute d'autres langages que le shell qui
peuvent répondre à ton besoin.
Bon, j'ai quand même tenté un ultime essai (voir ci-dessous) qui
semble faire ce que je souhaite mais c'est peut-être un peu tordu.
Qu'en pensez-vous ? Est-ce que ça répond bien au problème ?
À vrai dire, je ne sais pas si ça répond au problème car je n'ai pas en
tête d'exemple équivalent à ce que tu souhaites faire. Peux-tu donner un
exemple concret de besoin d'avoir les mêmes options pour plusieurs
programmes ? Quel genre de tâches font ces options ?
Il y a peut-être plus simple à faire qu'une usine à gaz. Dans le cas
contraire, il existe sans doute d'autres langages que le shell qui
peuvent répondre à ton besoin.
Bon, j'ai quand même tenté un ultime essai (voir ci-dessous) qui
semble faire ce que je souhaite mais c'est peut-être un peu tordu.
Qu'en pensez-vous ? Est-ce que ça répond bien au problème ?
À vrai dire, je ne sais pas si ça répond au problème car je n'ai pas en
tête d'exemple équivalent à ce que tu souhaites faire. Peux-tu donner un
exemple concret de besoin d'avoir les mêmes options pour plusieurs
programmes ? Quel genre de tâches font ces options ?
Il y a peut-être plus simple à faire qu'une usine à gaz. Dans le cas
contraire, il existe sans doute d'autres langages que le shell qui
peuvent répondre à ton besoin.
J'ai bien tenté un portage en Python par exemple avec un truc super
propre au niveau de la gestion des options mais j'ai très vite vu
qu'au niveau perf, ça n'avait plus rien à voir ce qui est assez
logique car avec Python on est dans du plus haut niveau avec de
l'objet etc. et ça a un coût en terme de mémoire forcément. J'ai
essayé, très modestement, le Perl aussi. C'était mieux au niveau
perf que Python mais malgré tout nettement moins bon que le shell sh
dont je dois dire que j'ai été assez bluffé par le faible coût en
terme de mémoire et de cpu. Après il y a le C bien sûr, mais je n'y
connais strictement rien en C. En fait, le shell me convient très bien,
voire parfaitement bien si j'avais la possibilité de factoriser la gestion
des options communes.
J'ai bien tenté un portage en Python par exemple avec un truc super
propre au niveau de la gestion des options mais j'ai très vite vu
qu'au niveau perf, ça n'avait plus rien à voir ce qui est assez
logique car avec Python on est dans du plus haut niveau avec de
l'objet etc. et ça a un coût en terme de mémoire forcément. J'ai
essayé, très modestement, le Perl aussi. C'était mieux au niveau
perf que Python mais malgré tout nettement moins bon que le shell sh
dont je dois dire que j'ai été assez bluffé par le faible coût en
terme de mémoire et de cpu. Après il y a le C bien sûr, mais je n'y
connais strictement rien en C. En fait, le shell me convient très bien,
voire parfaitement bien si j'avais la possibilité de factoriser la gestion
des options communes.
J'ai bien tenté un portage en Python par exemple avec un truc super
propre au niveau de la gestion des options mais j'ai très vite vu
qu'au niveau perf, ça n'avait plus rien à voir ce qui est assez
logique car avec Python on est dans du plus haut niveau avec de
l'objet etc. et ça a un coût en terme de mémoire forcément. J'ai
essayé, très modestement, le Perl aussi. C'était mieux au niveau
perf que Python mais malgré tout nettement moins bon que le shell sh
dont je dois dire que j'ai été assez bluffé par le faible coût en
terme de mémoire et de cpu. Après il y a le C bien sûr, mais je n'y
connais strictement rien en C. En fait, le shell me convient très bien,
voire parfaitement bien si j'avais la possibilité de factoriser la gestion
des options communes.