Posté par Marotte ⛧ .
En réponse au journal Args parser pour shell.
Évalué à 10.
Dernière modification le 15 février 2024 à 19:10.
C’est getopts, avec un s le builtin du shell. Non ?
Accessoirement c’est un composant de la norme POSIX. J’étais au courant de son existence et ce n’est certainement pas le fait que getopt ne soit pas POSIX qui m’avait fait l’abandonner, en faveur de getopts, parce que POSIX ça a son utilité mais c’est vraiment rébarbatif par rapport à un shell moderne, mais il y avait je ne sais plus quel point qui m’avait chagriné à l’époque où j’avais fait mon choix. Il faudra que je me penche à nouveau sur la question.
En fait, ça fait bien longtemps que j’écris des scripts shell, en bash, et je me suis rendu compte que c’était le langage que j’utilisais le plus. Comme par ailleurs « tout le monde » lui prête une réputation de langage préhistorique au fonctionnement absolument horrible, ça me donne encore plus envie de le connaître bien ^^. Depuis au moins dix ans j’écrivais des scripts avec ce que j’avais appris jusqu’alors, découvrant encore parfois de temps en temps, de manière fortuite, une nouvelle fonctionnalité, mais sans chercher à en apprendre plus.
Et bien, que la suffisance est une vilaine maladie en effet ! Je me souviens que de nombreuses années auparavant j’avais eu vent du « strict mode ». Je ma rappelle alors qu’à l’époque j’avais jugé cela comme une complication loin d’être indispensable et avais soigneusement oublié l’existence de cette « convention » (qui est plus que ça au final). Aujourd’hui, avec les années d’expériences acquises, quand j’ai relu de quoi il s’agissait, j’ai eu envie de mettre des baffes au moi du passé. Rien que l’argument de la nécessité d’activer l’option errexit (un des quatre points constituant ce qu’on nomme le « strict mode », qu’on pourrait d’ailleurs aussi appeler le « script mode » tout simplement) me semble aujourd’hui tomber sous le sens. Comment ai-je pu faire du Perl, du Python et trouver tout naturel qu’une erreur de syntaxe (par exemple), arrête l’exécution, tout en trouvant tout aussi normal que Bash puisse se comporter comme un canard à qui on a coupé la tête mais continue de marcher ? À l’évidence on supporterait difficilement de devoir se reloger à chaque fois qu’on fait une faute de frappe, ou qu’on essaye de supprimer un fichier inexistant, ou créer un répertoire qui existe déjà, pour prendre quelques exemples, quand on est en mode interactif, mais quelle idiotie totale de conserver ce comportement quand on écrit un script... Ce ne sont pas les quelques adaptations à apporter à sa façon de coder que cela implique qui justifient de ne pas activer ces option. Enfin, pour celui que j’étais à 20 ans il faut croire que si _o_.
Si tu trouves que je parle chinois cher lecteur ayant à écrire des scripts bash (et je suppose que zsh et ksh sont concernés aussi, peu ou prou à l’identique), rends-toi ce service, rends le à toute la profession, prends le temps de considérer http://redsymbol.net/articles/unofficial-bash-strict-mode/ C’est un peu chiant au début car ça force à modifier quelques automatismes qu’on a pu acquérir, mais sans le moindre doute, même après des années de déformation professionnelle j’ai réussi à m’y habituer rapidement et c’est effectivement bien plus confortable.
Je me demande combien de gens qui écrivent des scripts utilisent systématiquement ces options. Dans ma vie professionnelle je n’en ai jamais rencontrer. Ce serait même plutôt le contraire, comme des gens qui mettent systématiquement export devant une déclaration de variable, dont un qui l’a fait devant moi et, que j’ai pu interroger sur le moment et qui m’a répondu : « parce que des fois sans ça marche pas », et c’était une personne plus « expérimentée » que moi. Ou les éternels grep truc | wc -l, les echo lignes par lignes, et autres joyeusetés...
Et à contrario quand je lis certaines personnes, comme ici ou sur stackoverfow par exemple, ou même que je lis pour la première fois une partie du manuel et que je réalise que je faisais de la merde, je suis loin de penser que je maîtrise la chose.
Par exemple je viens de découvrir les builtins : enable, caller (et declare pas très longtemps auparavant bien que je connaisse local depuis un moment), et help bordel ! Qu’est-ce que j’ai pu man bash | grep -C5 truc comme un con ! /o\
Faites ce que vous voulez mais RTFM! On le dira jamais assez ! ^^
[^] # Re: getopt(1)
Posté par Marotte ⛧ . En réponse au journal Args parser pour shell. Évalué à 10. Dernière modification le 15 février 2024 à 19:10.
C’est
getopts, avec un s le builtin du shell. Non ?Accessoirement c’est un composant de la norme POSIX. J’étais au courant de son existence et ce n’est certainement pas le fait que getopt ne soit pas POSIX qui m’avait fait l’abandonner, en faveur de getopts, parce que POSIX ça a son utilité mais c’est vraiment rébarbatif par rapport à un shell moderne, mais il y avait je ne sais plus quel point qui m’avait chagriné à l’époque où j’avais fait mon choix. Il faudra que je me penche à nouveau sur la question.
En fait, ça fait bien longtemps que j’écris des scripts shell, en bash, et je me suis rendu compte que c’était le langage que j’utilisais le plus. Comme par ailleurs « tout le monde » lui prête une réputation de langage préhistorique au fonctionnement absolument horrible, ça me donne encore plus envie de le connaître bien ^^. Depuis au moins dix ans j’écrivais des scripts avec ce que j’avais appris jusqu’alors, découvrant encore parfois de temps en temps, de manière fortuite, une nouvelle fonctionnalité, mais sans chercher à en apprendre plus.
Et bien, que la suffisance est une vilaine maladie en effet ! Je me souviens que de nombreuses années auparavant j’avais eu vent du « strict mode ». Je ma rappelle alors qu’à l’époque j’avais jugé cela comme une complication loin d’être indispensable et avais soigneusement oublié l’existence de cette « convention » (qui est plus que ça au final). Aujourd’hui, avec les années d’expériences acquises, quand j’ai relu de quoi il s’agissait, j’ai eu envie de mettre des baffes au moi du passé. Rien que l’argument de la nécessité d’activer l’option
errexit(un des quatre points constituant ce qu’on nomme le « strict mode », qu’on pourrait d’ailleurs aussi appeler le « script mode » tout simplement) me semble aujourd’hui tomber sous le sens. Comment ai-je pu faire du Perl, du Python et trouver tout naturel qu’une erreur de syntaxe (par exemple), arrête l’exécution, tout en trouvant tout aussi normal que Bash puisse se comporter comme un canard à qui on a coupé la tête mais continue de marcher ? À l’évidence on supporterait difficilement de devoir se reloger à chaque fois qu’on fait une faute de frappe, ou qu’on essaye de supprimer un fichier inexistant, ou créer un répertoire qui existe déjà, pour prendre quelques exemples, quand on est en mode interactif, mais quelle idiotie totale de conserver ce comportement quand on écrit un script... Ce ne sont pas les quelques adaptations à apporter à sa façon de coder que cela implique qui justifient de ne pas activer ces option. Enfin, pour celui que j’étais à 20 ans il faut croire que si _o_.Si tu trouves que je parle chinois cher lecteur ayant à écrire des scripts bash (et je suppose que zsh et ksh sont concernés aussi, peu ou prou à l’identique), rends-toi ce service, rends le à toute la profession, prends le temps de considérer http://redsymbol.net/articles/unofficial-bash-strict-mode/ C’est un peu chiant au début car ça force à modifier quelques automatismes qu’on a pu acquérir, mais sans le moindre doute, même après des années de déformation professionnelle j’ai réussi à m’y habituer rapidement et c’est effectivement bien plus confortable.
Je me demande combien de gens qui écrivent des scripts utilisent systématiquement ces options. Dans ma vie professionnelle je n’en ai jamais rencontrer. Ce serait même plutôt le contraire, comme des gens qui mettent systématiquement
exportdevant une déclaration de variable, dont un qui l’a fait devant moi et, que j’ai pu interroger sur le moment et qui m’a répondu : « parce que des fois sans ça marche pas », et c’était une personne plus « expérimentée » que moi. Ou les éternelsgrep truc | wc -l, lesecholignes par lignes, et autres joyeusetés...Et à contrario quand je lis certaines personnes, comme ici ou sur stackoverfow par exemple, ou même que je lis pour la première fois une partie du manuel et que je réalise que je faisais de la merde, je suis loin de penser que je maîtrise la chose.
Par exemple je viens de découvrir les builtins :
enable,caller(etdeclarepas très longtemps auparavant bien que je connaisse local depuis un moment), ethelpbordel ! Qu’est-ce que j’ai puman bash | grep -C5 truccomme un con ! /o\Faites ce que vous voulez mais RTFM! On le dira jamais assez ! ^^