Marotte ⛧ a écrit 8717 commentaires

    _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. ^{^}

Donc en 3 jours et une dizaine de commentaires tu n'avance rien, pas l'ombre d'une information

Totalement d’accord. Que de pures suppositions. Aucune contestation de ma part sur ce point. Mais je ne dois rien à personne ici en dehors du respect élémentaire.

et tu te targue de mettre en garde les gens.

Mais où, sérieusement ? Je me targue de beaucoup de choses, mais qu’est-ce qui te permet de dire que je « mets en garde » qui que ce soit ? Je donne juste mon avis, et sans prétendre savoir quoi que ce soit ni me permettre de dire à quiconque de croire, faire ou penser ceci ou cela. Si je me trompe s’il te plaît indique moi quelle partie de ce que j’ai posté te porte à supposer cela.

Tu es vraiment à ce point intellectuellement fragile (ou plutôt sujet à un manque de confiance en toi) pour juger potentiellement néfaste une personne qui ose émettre un avis non-éclairé sur tel ou tel sujet ? Tu as peur que l’ignorance et la bêtise que tu m’attribues te contaminent ? Ou bien ce sont tes prochains, pauvres choses… que tu te fais un devoir de protéger du mensonge et guider vers la vérité ?

Tu ne vois vraiment pas que ça ne tiens pas debout ?

Tout ce que je vois c’est que tu te permets de dire que je ferais mieux de « fermer ma gueule » sous prétexte que mes propos ne te plaisent pas, et qu’ils sont, en partie, possiblement, voire probablement, fallacieux.

Penses-tu vraiment qu’il soit réaliste d’exiger que tous ceux « qui ont tort » ne puissent pas s’exprimer ? Ce qui amène à la question qui en découle naturellement : penses-tu avoir toujours raison quand tu t’exprimes ?

Ne te sens pas obligé de répondre à la question, essaye déjà d’y réfléchir !

Cette discussion a déjà un certain âge et tu ne t'appuis sur aucun élément concret, tu fais preuve d'aucun intérêt en vers ce qui est vérifiable et concret. Cen'est pas une hypothèse que tu présente, c'est une croyance. Tu semble te l'être forgé plus vite que tu n'avais de temps pour lire le lien et changer cette croyance n'est pas un sujet pour toi.

On n’a clairement pas la même appréciation du temps qui passe. Cette discussion aussi bien que le sujet sur lequel elle porte n’a pas un certain âge. On parle en jours, et les tenants et aboutissants de l’affaire, s’ils sont mis à jour, ne le seront pas de si tôt. En fait ce que j’ai du mal à comprendre c’est qu’on puisse prendre mes « élucubrations » (je n’ai aucun problème avec ce qualificatif) pour des conclusions. Car il est absolument évident pour moi qu’on ne peut rien conclure pour le moment, ni sur le vol de données, ni sur l’utilité de la plainte où la stratégie de tous les organismes concernés et de leurs intentions.

Si je n’ai pas lu plus loin qu’une rapide lecture en diagonal de même pas la moitié de l’article c’est précisément car je sais qu’à l’heure actuelle il n’y a aucune information intéressante, et que je préfère largement ne pas me polluer l’esprit avec des détails qui n’en sont pas, et porter ma réflexion à partir d’éléments isolés tels que "Viamedis", "Almerys", "vol de données", "assurances", "recours en justice". Tu ne sais pas quelles lectures j’ai eu en apprenant ce fait divers, et tu t’en fous probablement pour de très bonnes raisons, mais sache que ce n’était certainement une lecture attentive d’un article de presse qui comme toujours prétend présenter « le plus factuel et le plus complet de l’information sur le sujet », explicitement ou implicitement. Et pour ma part je ne me permets pas de prétendre mieux que les autres, que moi en l’occurrence, avoir une vision plus fidèle de la réalité, une vision de nature supérieure.

celui de ne pas chercher à comprendre ce qui est devant nous.

Et c’est moi qui suis pétri de croyance ? Tu ne sais rien des informations que j’ai ou que je n’ai pas, tu ne fais que supposer à partir de ce que j’écris ici. Au point même de pouvoir affirmer savoir ce que je pourrais chercher à connaître ou non de cette affaire.

c'est une forme de consumérisme, il faut réagir à tout prix et tenter de générer des interactions

Quel rapport avec le consumérisme ? Générer des interactions je veux bien, ça marche effectivement.

Les lanceurs d'alerte portent des preuves au public, il ne s'agit pas d'énoncer des opinions sans chercher à savoir si elles sont vraies ou pas.

Lanceur d’alerte ? De mieux en mieux… Un lanceur d’alerte écrirait « Je suis p-e totalement à côté de la plaque » à la suite de son propos ? Utiliserait le conditionnel ?

J’émets l’hypothèse (c’est clair là ?) que mes propos te dérangent pour la simple raison qu’ils vont à l’encontre de ta vision du monde mais que ta confiance dans ton propre jugement ne va pas jusqu’à pouvoir les ignorer purement et simplement.

tu ne t'appuis sur aucun élément concret

Tout à fait, seulement sur mon expérience, et je ne donne que ma première impression sur ce sujet. C’est relativement évident malgré tout pour quiconque ne présume pas de manière péremptoire connaître et pouvoir juger de la manière de fonctionner de son interlocuteur, de ce qu’il a lu ou pas. Pas étonnant dans ce cas que tu suggères de manière totalement capillotractée que je pourrais prétendre avoir le rôle d’un lanceur d’alerte en écrivant ce que j’ai écrit…

Je ne trouve pas que la simplification de la communication dont je parle dans le message que tu cites s’applique ici. Je ne fais qu’émettre l’hypothèse qu’il se pourrait que l’évidence de ce dépôt de plainte, qui semble manifestement incontestable pour beaucoup ici, n’est peut-être pas l’explication la plus fidèle à la réalité, et que, justement, l’évidence n’est peut-être qu’apparente.

Si j’ai tort de douter alors tant mieux, je serais juste passé pour un con ignorant. Si c’est le prix à payer pour soulever, potentiellement, de possibles aspects plus complexes d’un problème, trop rapidement ignorés car semblant précisément tomber sous le sens, je n’y renoncerais jamais (ou seulement pour des raisons pratiques bien particulières)

Donc non, je ne trouve absolument pas cocasse mon hypothèse, que je peux comprendre qu’on prenne pour une conclusion d’après le ton que j’emploie, mais qui n’en ai pas une.

En effet, et tu fais bien de le préciser. Merci pour la correction.

Est-ce niveler par le bas le niveau de communication pour une personne émettant un message d’essayer d’être compréhensible pour son public et de pas être trop jargonnant ?

Évidemment. Je déplore, à partir de mon impression, peut-être erronée, qu’on penche trop souvent vers la volonté d’être le plus compréhensible possible, au détriment de la conservation de la pertinence et de la qualité.

Si tu prends un groupe de cent personnes, si seulement quinze peuvent comprendre ce que tu dis, tu as clairement besoin d’adapter ton message pour qu’il diffuse un peu plus. Maintenant, si tu as quatre-vingt douze personnes sur cent qui comprennent, faut-il réellement adapter ton discours pour être inclusif auprès des huit personnes qui ne suivent pas ?

Je ne crois pas pour ma part. Et je vais même plus loin : ce n’est pas leur rendre service. Sachant que sur ces huit personnes il y en a peut-être une et demie qui va exprimer un grief relatif à cet aspect de ta communication. Six n’en auront rien à foutre, et deux seront en désaccord, qu’ils comprennent ou pas, parce que c’est leur nature, leur droit à la différence, et ils ont soufferts, et ils s’aplatiront jamais devant l’oppresseur intellectuel que tu es.