Marotte ⛧ a écrit 8797 commentaires

Je sais pas plus ce que c’est qu’est un geoguesser qu’un wordle _o_

ROFL

plop June VII V Pepsi again belleck dbfen 4 FY777

Rule 11 j’abandonne :)

C’est exactement pour ce genre de possible galère que je pense qu’il vaut mieux rallonger le mot de passe que mettre un caractère « exotique ». J’ai eu le soucis assez régulièrement par le passé, je sais maintenant où sont le w, le m, le z, et quelques diacritiques, ou que les chiffres nécessitent pas de Shift, avec une dispo qwerty.

Il me serait jamais venu à l’idée d’utiliser un qwerty (en tant que français), les français qui font ça, c’est une question d’habitude ? Les premiers PC vendus en France avaient des claviers qwerty ? Ou bien vous utilisez une disposition qwerty sur un clavier qui est « physiquement » azerty par snobisme pour une bonne raison ?

À ça peut s’ajouter encore un sur-couche de problème… Il y a quelques temps j’ai acquis un clavier à touches mécaniques, pour voir ce que ça donnait. Il se trouve qu’en plus d’avoir des touches mécaniques elles ont des loupiottes, ça aucun problème, mais c’est un clavier dit « de gamer », on peut donc, par exemple échanger les touches qzsd avec les flèches. Je l’ai appris par hasard suite à un appuis involontaire sur la « bascule » qui active ce réglage, bah je me suis trouvé con. Surtout que débrancher le clavier un moment (le temps de brancher un bon vieux clavier de merde avec des touches « caoutchouc » pour finir mon taf) et bien ça ne remet pas la configuration à zéro (oui c’est sûr c’est plutôt une feature je dis pas ^^). J’ai fini par trouver mais ce fût un peu laborieux.

Au sujet des touches mécaniques : ya pas à dire le toucher est plus agréable, par contre j’ai certaines touches qui parfois ne s’activent pas. J’en ai déjà remplacé quelques une (le clavier était livré avec quelques mécanismes de remplacement…) mais c’est le genre de truc qui ne m’étais jamais arrivé avec des claviers normaux à 10 balles… Ceci dit je ne suis pas capable de dire pourquoi ça déconne précisément, vu qu’il y a un tas de raisons possible, alors je suppose que c’est une conjonction de toutes :

• C’est pas le premier prix mais quand je vois les prix qu’atteignent les claviers mécaniques je sais que j’ai pas le top

• Je suis un bourrin et les touches prennent cher, ces bêtes là sont probablement plus délicates que les claviers classiques

• Les poils d’animaux ont tout l’espace nécessaire pour aller se foutre où il ne faut pas (j’ai déjà ôté toutes les touches (enfin les « capuchons », les mécanismes c’est assez relou à sortir…) pour dégager les poils, mais je vais pas faire ça tout le temps.

• N’ayant jamais eu une motricité fine très développée et le temps passant, mes doigts ne frappent plus forcément là où mon cerveau s’attend à ce qu’ils frappent avec une précision suffisante. ^^

Pour les plus jeunes (ou les très vieux) : https://www.youtube.com/watch?v=zGvmL21pv6c

:p

Ah si, une remarque quand même. C’est quelque chose que je faisais aussi, en préfixant pour éviter tout risque de collisions mais de ce que j’ai compris, par convention les identifiants (ie: non de variable) en majuscule sont à réserver aux variables d’environnement.

Mais bon… je note que tu préfixes par _ par prudence, je crois pas que ce soit très grave comme façon de faire, perso je ne vais pas réécrire tous les scripts que j’ai fait avec des variables en majuscules pour les passer en minuscules ! :) Le plus souvent je me contentais de les préfixer toutes par une chaîne dériver du script. par exemple un script "UltimateTrucWrapper" je préfixais par UTW_. Avec ça je pense être assez tranquille. Mais maintenant j’ai changé j’en ai plus rien à branler j’utilise des minuscules avec un nom le plus descriptif possible, exemple : lobby_carpet_color_RVB :)

    _AXM_ARGS_FILE=$(mktemp -t ${__AXM_FILE_PREFIX}-auxilium_args.XXXXXX)
    _AXM_ARGS_VALUE=$(mktemp -t ${__AXM_FILE_PREFIX}-auxilium_value.XXXXXX)
    _AXM_LIST_ARGS=$(mktemp -t ${__AXM_FILE_PREFIX}-auxilium_list_args.XXXXXX)
    _AXM_LIST_OPT=$(mktemp -t ${__AXM_FILE_PREFIX}-auxilium_list_opt.XXXXXX)

Il servent à quoi les .XXXXXX finaux ?

Si tu veux que le nom soit propre à l’exécution (au cas peu probable où on exécuterait ton script 2+ fois en parallèle (dans un framework plus large qui l’inclurait par exemple…)), tu devrais p-e utiliser $$ en lieu et place de .XXXXXX ?

Après lecture rapide de ton script je dois dire que je n’ai pas le volonté de vraiment étudier le truc. Mais je le garde dans mes bookmark et le testerai p-e à l’occasion.

Et j’apprends l’existence de /usr/bin/tabs, l’aide parle de COBOL, FORTRAN et S/370, entre autre, je t’avoue que je suis trop intimidé pour essayer de comprendre à quoi ça sert ! ^^

Je ne connaissais pas ${X,,} ni ${X^^} (c’est dans la « cheat sheet » à laquelle je me réfère mais je n’ai pas pris le temps de tout lire (parce qu’il m’est illusoire de tout retenir de toute façon…)).

J’ai vu que declare permettait effectivement de faire ça. Cependant je ne vois pas quels sont les cas d’usage. Vous auriez des exemples ?

si tu n'utilise pas un autre langage que tu donne à manger à un compilateur ou un interpréteur

Alors je mets de côté les langages compilés qui ont indéniablement des avantages sur les interprétés. Mais je ne vois pas ce que tu veux dire si tu parles d’interpréteur. Bash est au même titre que Perl et Python un langage interprété. Le fait que Python expose l’étape intermédiaire du bytecode ne change pas grand chose.

En d’autres termes, en quoi Perl et Python seraient de véritables langages interprétés et pas Bash ?

Les « exécutables de ma distribution » ils ont cet avantage sur les bibliothèques Python d’être nettement plus stabilisés en terme d’API… Sans parler de la quasi trivialité de la mise en place de « l’environnement d’exécution », qui s’il n’est pas très complexe dans le cas de Python, encore moins de Perl, n’est pas aussi trivial que les binaires qui constituent l’environnement d’exécution d’un script Bash.

Ça fait combien de temps que pip/pip3 ne permet même plus de faire un "search" ?

il n'est pas limitant (va dessiner des Qrcode en shell)

Je pense qu’on touche là à un point central, qu’est-ce que "le shell" désigne si on parle programmation ?

Est-ce uniquement Bash (ou zsh, etc…) ou bien est-ce qu’on n’y inclus l’ensemble des binaires disponibles ? Bash et les autre shells sont des langages que je qualifierais de « glue », sans binaires comme curl ou grep ou find etc… on ferait pas grand chose.

Les « bibliothèques » du shell ce sont les « standalone » que tout bonne bibliothèque fournie systématiquement.

En interactif ils peuvent être très pratiques

Oui, en interactif je ne réécris pas toute ma commande si je veux la relancer avec un grep dessus… Donc j’UUOC sans honte comme tout le monde, comme tu dis c’est très pratique.

Les UUOC ne sont que des problèmes de puristes, ils ne posent de véritables problèmes que d'un point de vue esthétique.

Là par-contre je m’inscris en faux. C’est d’abord un problème si ton script, ou ta fonction dans ton script, est amenée a être exécutée « plein de fois ». Une instruction qui prend 15ms au lieu de 2ms ça change rien si tu l’exécutes une seule fois. Si c’est quelques millions, ou même quelques milliers de fois, ça commence à avoir son importance.

Donc clairement, ce n’est pas une question purement esthétique.

toute une série d’instructions/lignes entre le changement de IFS et son rétablissement.

Oui en effet. Je ne vois pas de cas d’usage mais ça ne veut clairement pas dire qu’il n’y en a pas.

le shell utilise IFS quasiment partout

Tu veux dire des commandes du shell comme ls, xargs ou autre qui pourraient avoir leur comportement modifié à cause de la modification de IFS ? Ça m’étonnerait (ou plutôt j’espère que non ^^). Je pense que tu parles du reste du code du script, voire de script externes appelés par celui-ci ?

Et heureusement la modification ne se propage bien-sûr pas au « sur-shell » qui a lancé le script.

$ printf "%q\n" "$IFS"; echo -e 'IFS=4\nprintf "IFS vaut : %q\\n" "$IFS"; exit 4\n' > script; bash -f script; printf "%q" "$IFS"

$' \t\n'
IFS vaut : 4
$' \t\n'

(je sais c’est moche, mais c’est représentatif)

Et c’est un bon exemple de cas « àlakon » où un double échappement se justifie, encore que, c’est juste pour que le fichier "script" généré ait pas la gueule de travers :)

utiliser perl/python/ruby.

Il y a clairement des avantages, mais qui viennent bien sûr avec quelques inconvénient. Dans les avantages je pense d’abord au fait de la cohérence du langage, surtout pour Python, mais Perl est aussi exemplaire sur ce point (bien que les deux soient absolument différent, et à condition de ne pas recourir excessivement à la puissance d’abstraction de Perl ^^). Par rapport au shell(s) Unix c’est le jour et la nuit.

Par contre pour « qui doit durer », je pense que ça dépend de si on parle de « qui doit être étendu souvent, par de nombreuses personnes » ou « qui doit être laissé dans un coin et voir passer les upgrades systèmes sans demander la moindre attention ». Dans le second cas Python est pas ouf, d’expérience, à partir du moment où on utilise quelques lib externes ça explose fréquemment à la version d’OS N+1. Pas le shell.

Je trouve que la taille du code joue beaucoup aussi, la programmation objet de Python, dès que le programme devient relativement complexe, ça aide énormément, en plus de la syntaxe et du paradigme beaucoup plus cohérent auquel je faisais allusion précédemment.

Pour ma part, en tout cas dans le cas où un test est nécessaire. Généralement c’est pour conditionner l’exécution d’une autre commande ou d’une fonction. Alors à moins d’être dans le cas d’une « conditionnalité complexe » (ie: un if … elif … else … fi), je fais :

grep -q truc fichier || action

Le || pour coller à ton exemple avec -ne 0, mais si c’est au contraire -eq 0 (ie: on fait l’action si la condition est "success"), alors la même chose avec &&.

Je fais parfois même des condition || { action1; && action2; } (ou l’inverse…) mais j’avoue que là ça devient assez illisible et il vaut mieux recourir à un if même si on peut faire sans.

Flemme de vérifier (et pas sûr que ça change quoi que ce soit à l’exécution…) mais si c’est la condition “ya des lignes ou pas ?” qui t’intéresse, le -c de grep n’est même pas nécessaire :) Et l’intérêt à ne pas le mettre dans ce cas ce serait qu’à la simple lecture du début de la ligne, juste les options du grep, tu sais qu’on ne s’intéresse pas aux nombres de lignes qui matchent mais juste s’il y en a ou pas.

Si je pouvais bosser qu’avec des gens doués comme vous ! ^^

L’exemple que j’ai donné c’est ce qu j’ai pu voir, assez souvent même, dans un cadre professionnel. C’est des trucs que j’ai très sûrement fait moi-même en maternelle de shell. On dirait les exemples qu’on enseigne. Typiquement tu expliques cat, puis | et introduit grep et pour illustrer tu montres cat fichier | grep truc, après tu expliques wc, et pour montrer toute la puissance de la notion de pipe, qu’on peut chaîner, tu montres cat fichier | grep truc | wc -l. Etc… etc…

Donc j’ai l’impression que bien des gens se sont arrêtés là… Mais loin de moi l’idée de les blâmer, enfin pas trop et pas tous ^^. Tout le monde n’a pas le goût de la programmation et on peut sûrement concevoir les métiers de l’informatique autrement, avec une vision plus clickodrome que ligne de code du bousin. Ça n’implique pas d’être débile pour autant, chacun ses forces et ses faiblesses, et surtout, sa vision des choses…

J’ai toujours pas compris comment quelqu’un a pu trouver que c’était une bonne idée, et comment ça a pu être validé jusqu’à la mise en production.

Suggérer l’idée que curl et wget c’est en fait la même chose, que cette soi-disant richesse, cette variété des logiciels libres était bien une légende. Oui Madame, nous le disions ! Une sorte de cancer, oui, appelons un chat un chat. C’était une fake-news écœurante, probablement entretenue par des trolls sales et mal rasés comme on s’est évertué à vous le dire depuis Windows 95. Donner deux noms différents à un même programme c’est assurément le signe d’une condition psychiatrique particulière et qu’il est de notre devoir le plus absolu d’offrir à l’humanité (pour un prix raisonnable) les logiciels qu’elle mérite, les seuls logiciels dignes de dépenser de l’argent et concéder une perte de sa liberté, pour le meilleur !

DISCLAIMER : Je ne vis pas dans le slip du Bill Gates de 2002, mais dans le mien. Je n’ai aucun élément factuel étayant le propos ci-dessus. Toute survenu d’idée chez le lecteur de nature à provoquer un avis quelconque est indépendante de ma volonté et pure coïncidence. Ce contenu vous est fourni… Aziz ! Si ya un problème c’est pour toi !

if [ "$(basename $0)" = "auxilium" ]; then
    echo "You can't use this script directly"
    echo "You can view an example by call /usr/bin/auxilium-test"
    exit
fi

Si j’ai pu critiquer les echo sur plusieurs lignes dans un autre post j’espère que tu ne te remettras pas en question sur ce point, car ça a le mérite d’être nettement plus lisible que la manière dont je m’y prends moi et finalement je ne vois pas ce qui me permet de critiquer cette façon de faire.

J’allais dire autre chose mais je vais fermer ma gueule parce que j’avais juste oublié que ton script se devait d’être POSIX et je ne peux donc pas te donner de solution à l’éventuel et très hypothétique problème que je vois… Or « Pas de solution, pas de problème. »

Par contre pour les deux fonctions suivantes :

_to_lower(){
    echo $(echo $1 |tr -s '[:upper:]' '[:lower:]')
}

_to_upper(){
    echo $(echo $1 |tr -s '[:lower:]' '[:upper:]')
}

Tu ne pourrais pas faire simplement :

_to_lower(){
    echo "$1" |tr -s '[:upper:]' '[:lower:]'
}

_to_upper(){
    echo "$1" |tr -s '[:lower:]' '[:upper:]'
}

?

L’absence de quote dans le cas de echo pose rarement des soucis mais s’il y a un * dans ton argument ça va quand même faire des trucs potentiellement ennuyeux et assurément indésirables.

Mais surtout, je ne vois pas pourquoi tu fais un « echo d’un echo », ça ne fait pas la même chose effectivement, dans ton cas tu appelles un sous-shell, mais en l’occurrence je ne vois pas en quoi c’est utile. (Note que je n’ai bien sûr pas lu tout le script avant de commenter, c’est ma spécialité ! ;) Je pense toujours pouvoir le faire, mais là j’ai plus le temps ce « soir ».

Je les renseigne dans une cartouche de commentaire en début

Je l’ai fait aussi sinon ce serait même pas la peine… Et c’est le fait de devoir faire des head -n20 avant de lancer le script qui me rappelle que ça devient critique. :) (je sais que le "n" pour la commande head n’est obligatoire, mais comme il l’est quand il y a d’autres options je le mets systématiquement…)

j’essaie de prévoir un mode interactif

Alors ça c’est le truc qui me vient jamais à l’esprit et que j’ai du mal à envisager, mais sans aucune bonne raison.

getop pour bash

Faut vraiment que j’aille voir pourquoi j’avais décidé de ne plus utiliser ce truc. Vu que c’est grosso modo la même époque où j’ai jugé que le strict mode c’était bof, il y a des chances que ma décision ait été tout aussi conne concernant getopt. :)

Pas vraiment pris de le temps de regarder de près mais je pense que je le ferai. Juste lu le README, il y a une chose qui me fait tiquer :

auxilium_parse $@

Ne pas mettre de double quotes ici n’est-ce pas à coup sûr le meilleur moyen qu’une valeur passée à une option telle que 'j’ai un espace yo!' ou "moi aussi !" foute le bordel ?

Si j’ai bien compris :

 "$@"

a la particularité de se « développer » (? pas sûr du terme…) en "element1" "element2" "element3" … etc… alors que sans les doubles quotes, il est strictement équivalent à $*, et se développera en element1 element2 element3 …, donc sans quote entourant chaque élément.

Jamais eu autant de prise tête avec les échappements en Python, j’ai l’impression qu’en shell c’est une des difficulté majeure de bien comprendre en quoi '' "" $'' sont différents, et que IFS est un élément clé (et strict mode pas une chose de seconde importance…).

J’ai des souvenirs d’en arriver parfois à des triples échappement jadis… or il n’y a que le double échappement qui puisse être justifié dans certains cas, assez rares, mais quand tu triples échappe faut aller prendre l’air et faire une sieste ! ^^

Au sujet de IFS, j’ai jamais compris l’utilisation d’un OLDIFS pour rétablir le truc après eu besoin de le modifier. Quand j’ai besoin de le modifier c’est généralement pour un un read, et en faisant IFS='caractère ad-hoc' read … à la suite du read IFS a toujours sa valeur. _o_ (\t\n bien sûr ! pour ceux qui suivent)

Comme on peut faire par exemple, dans un shell interactif : LANG=C man bash si on a habituellement sa locale en fr mais qu’on veut lire la sainte bible en anglais. Ça ne va pas changer la valeur de LANG pour les commandes suivante, juste pour la commande qui suit l’affectation (un truc que j’ai eu du mal à capter à mes débuts clairement)…

Over 84.6% of Bash scripts you can find on the Internet don't accept command-line arguments, which greatly limits their usefulness. This has a reason - Bash doesn't make command-line argument parsing easy.

Le dernier script que j’ai écrit, un truc perso. J’ai pas voulu « me faire chier » avec les options, je me suis dit que des paramètres positionnels ferait l’affaire, au moins dans un premier temps. Après tout, il est toujours possible de spécifier "" pour un paramètre si on veut laisser la valeur par défaut. La seule contrainte c’est de se souvenir de l’ordre de ceux-ci.

J’en suis à onze… amendoné va falloir que je fasse quelque chose. Ceci dit, quand on utilise le script de manière intensive c’est pas insurmontable… Mais une autre personne, ce qui inclus son moi futur qui voudra utiliser à nouveau le script après avoir cessé de le faire pendant une certain temps, elle risque une atrophie capillaire potentiellement conséquente. :/

Pour en revenir à la phrase que j’ai citée et qui est issue du site pointé par Gil Cot : je ne trouve pas que ce soit plus facile en Python (et en Perl j’en pas fait assez pour avoir un avis). Le peu d’expérience que j’ai avec d’autres langages me permet pas d’avoir un avis sur ceux-ci non plus. Mais ce que je veux dire : c’est une problème intrinsèquement complexe… et si un des paramètre est de nature à être une liste ? Et si je veux que si telle option est présente, telle autre soit ignorée ou interdite (et est-il plus judicieux de l’ignorer ou de l’interdire ?), et surtout : si je veux une option qui puisse optionnellement prendre une valeur ? (ie: option absente → cas 1, option présente sans valeur → cas 2, option présente avec une valeur → cas 3). Mixer tout ça, tout en souhaitant laisser aux utilisateurs la possibilité de les spécifier dans l’ordre qu’ils souhaitent ? ça peut devenir vite un facteur criminogène !

Je pense à le gestion des options de ffmpeg pour ceux qui connaissent. L’implémentation ne doit pas être triviale à mon avis. Sachant qu’en plus le comportement, les possibilités d’option peuvent varier selon le paramétrage de la compilation…

Message supprimé par l’auteur. Un jour j’apprendrais à lire tout avant de commenter !

toto=$(cat fichier | grep truc | wc -l) suivi d’un if [ $toto -eq 1 ] … bien sûr tant qu’à faire :)

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 ! ^^

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 "${@}"; do
  shift
  case "${argument}" in
     ('--verbose')             set -- "${@}" '-v' ;;
     ('--help')                set -- "${@}" '-h' ;;
     … … …
     … … …
     (*)                       set -- "${@}" "${argument}"
  esac
done

à 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.

Bien vu!

Ceci dit si $RANDOM renvoie des valeurs de 0 à 32767 la distribution des tirages reste possiblement faussée, plus ou moins, voire pas du tout, selon la borne supérieure.

Je peux me tromper mais avec 42, vu que 32767 / 42 = 780 + 7, les nombres de 0 à 7 ont plus de chance de sortir. Un probabilité supérieure de 1 / 781, soit environ 0,13 % (?)

est considérée par beaucoup comme mettant en échec la vision déterministe

C’est vrai que les découvertes de la physique quantique remette tout en question. On parle aussi de « physique subatomique » je crois, ces deux termes sont interchangeables ? Ou bien la physique quantique est une conception, une approche particulière de la physique subatomique qui est un domaine plus large (potentiellement…) ?

Même la relativité générale n’a plus aucune pertinence à cette échelle là me semble-t-il… L’intrication quantique aussi laisse songeur.

Je peux très bien imaginer que la question de savoir si le principe déterministe est encore lui aussi pertinent doit donner lieu à de nombreux débats. Pour l’instant impossible d’être sûr. ^{^}