xulops a écrit 315 commentaires

Oui, c'est moi ça marche® avec sudo.
C'est peut-être la différence entre getenv("USER") et getenv("LOGNAME").

Je viens de mettre en ligne une version 1.1 qui permet de modifier le format du nom du fichier de sortie. Tu peux donc le télécharger et le lancer par la commande suivante :

sudo php latencycheck.php -d 1 -m icmp -f list_address -o %DATE/%IP

Donc je suppose que tes serveurs ne repondent pas sur le port 7. J'ai un routeur comme ça chez moi qui ne repond pas sur le port 7 aussi.
Quand l'iP ne répond pas, le script met le timeout comme réponse.

J'en ai fait un script bien plus complet là : https://xulops.net/forge/latencycheck.php
Tu pourras changer le port, voir utiliser d'autres méthodes de mesure de la lantence (en simulant un ping ICMP en PHP, voire en utilisant la commande ping de la distro).

Merci pour ce retour.

En fait, je n'ai pas utilisé les fonctions PHP posix_… suite à ce commentaire d'Andy sur php.net. Ce commentaire date de 11 ans, mais je n'ai aucun moyen de savoir si maintenant toutes les distribs compilent PHP avec ces fonctions, donc dans le doute je fais sans.

Mais ce n'est pas grave, pas besoin des fonctions PHP posix_… pour récupérer l'uid d'un user, il y a déjà la fonction get_user_uid dans le script qui fait ça, donc j'ai modifié le script (v2.0.1) de la façon suivante pour tester si l'uid est égal à 0 au lieu du nom du user :

// root ?
$user = getenv("USER");
$user_uid = get_user_uid($user);
if ($user_uid != 0) {
    display("[!!] Fatal error : this script must run as root user");
    exit();
}

Non, sinon le SPF ne sert plus à grand-chose… je ne considère pas que les serveurs Orange comme sources fiables pour mes mails.
Je pourrais certes le mettre à ~all et laisser le serveur du client décider si c'est du spam ou pas. J'ai fait le fainéant, j'ai utilisé une autre adresse mail. C'est juste pour un seul client, je ne vais pas perdre trop de temps là-dessus.

abuse@orange.fr

J'ai récemment eu un problème de mails aussi avec eux, mais d'une autre nature : mon enregistrement SPF est en -all, donc un client ayant un mail avec un nom de domaine refusait mes mails parce que les serveurs Orange font relay (vu dans l'avis de non-expédition), donc forcément le serveur final voit le mail venir d'un serveur d'Orange au lieu de mon serveur SMTP, donc refus.
J'ai eu l'explication (que Orange faisait relay pour les mails de ce domaine) en contactant cette adresse abuse, qui a répondu plutôt vite (3 jours après).

Voila un script vite fait en PHP, il faut le nommer check_address.php (car il s'auto-lance pour chaque mesure) :

<?php
// check_address.php

function latence($host, $port = 7, $timeout = 10) {
    $ts = microtime(true);
    $f = @fsockopen($host, $port, $errno, $errstr, $timeout);
    $result = microtime(true) - $ts;
    if (! $f) {
        $result = $timeout;
    } else {
        fclose($f);
    }
    return round($result * 1000, 0);
}

if (! isset($argv[1]) || ! isset($argv[2])) {
    // *******************************************************
    // daemon principal -> lance les pings toutes les secondes
    // *******************************************************
    $list_address = @file_get_contents("./list_address");
    $t_ip = explode("\n", $list_address);
    // nettoyage
    for ($i = 0; $i < count($t_ip); $i++) {
        $t_ip[$i] = trim($t_ip[$i]);
        if ($t_ip[$i] == "") unset($t_ip[$i]);
    }

    $time = time();
    while (true) {   // boucle infinie, il faudra killer le process pour terminer le programme
        while ($time == time()) usleep(10);
        $time = time();
        // lancement des mesures
        foreach ($t_ip as $ip) {
            echo date("Y-m-d H:i:s", $time)." : Mesure de $ip\n";
            system("php check_address.php ".escapeshellarg($ip)." $time > /dev/null 2> /dev/null &");
        }
    }
    exit();
} else {
    // **********************************************************************
    // programme appelé par le daemon principal -> mesure latence de cette IP
    // **********************************************************************
    $ip = trim($argv[1]);
    $time = (int) $argv[2];
    // mesure de la latence de cette IP
    $latence = latence($ip);
    // enregistrement de la mesure dans ./jour/ip
    $jour = date("Y-m-d", $time);
    if (! is_dir("./$jour")) mkdir("./$jour");
    if ($f = @fopen("./$jour/$ip", "a")) {
        fputs($f, date("H:i:s", $time)." ".$latence."ms\n");
        fclose($f);
    }
}

?>

La latence est mesurée en faisant un fsockopen sur le port 7. On peut aussi facilement faire du vrai ICMP avec socket_connect et consorts si besoin (à voir ta définition de "latence").
Le timeout est à 1s par defaut, pour éviter d'engorger la machine avec des process forkés qui se termineraient plus lentement qu'ils ne sont lancés, mais tu peux l'augmenter si tu surveilles un peu tout ça en cours d'execution.
Si tu surveilles beaucoup beaucoup d'IP, faut voir aussi si la machine suit le rythme.

Mesurer la latence toutes les secondes, n'est-ce pas un peu excessif ? Ca va te faire 86400 mesures par jour et par IP ! Une mesure toutes les 30 secondes ne suffit pas ? En fait c'est quoi le but du jeu ?

Vu que la mesure peut prendre du temps, si la latence est supérieure à 1 seconde, tu prévois quel comportement ? Il y a au choix :
- faire le bourrin et lancer une mesure toutes les secondes, même si l'IP est aux fraises et met trois plombes à répondre, quitte à aggraver sa triste situation par tes mesures.
- ne pas lancer d'autres mesures tant que la précédente n'a pas aboutie, ce qui donnera des trous dans les mesures, mais alors tu as aussi deux choix :
-- lancer une mesure dès que celle qui a mis plus d'une seconde est terminée, donc on n'est plus calé sur des secondes pile-poil.
-- attendre la prochaine seconde pile-poil pour lancer la mesure suivante pour être calé avec les mesures précédentes.

Faut déjà que tu décides quel comportement adopter, cela en fonction de ton besoin. Ensuite faire le script ne sera pas difficile : un script principal qui lance autant de daemons que d'IP dans le fichier, chaque daemon fait la mesure (en fonction du comportement que tu as choisi) et stocke la valeur dans un fichier ou BDD.

Avoir les 10 polices n'est en effet déjà pas gagné, mais quid de leur contenu ? je doute qu'elles soient toutes unicodes complètes (en fait, je suis certain qu'elles ne le sont pas, même en laissant de côté Symbols et ZapgDingbats), donc s'il n'y a pas de problème pour l'anglais et quelques variations de charset proches, ça doit merdouiller copieusement pour l'arabe, le mongolien, le chinois, le japonnais, et bien d'autres…
Bref, ce n'est pas une bonne idée de compter sur ces 10 polices, mieux vaux inclure les caractères utilisés, voire la police complète si c'est un roman.

Au passage, il me semble qu'il est possible d'embarquer les polices dans le PDF. Perso je préfère ça, justement pour éviter les surprises en changeant d'appareil.

En fait, c'est même mieux que ça, il y a trois choix lors de la création :
- ne pas inclure les polices (fichier léger)
- inclure les polices utilisées (fichier lourd)
- inclure uniquement les caractères utilisés (fichier assez léger)

Perso je code en générant toujours la troisième option, qui est un bon équilibre entre la taille du fichier et l'assurance qu'il soit correctement affiché partout.

Donc dans le cas du journal, "simplement" (pas toujours simple en réalité, faut savoir toucher les bonnes personnes) dire à l'organisme en question d'inclure les caractères utilisés dans le PDF.

Je n'ai pas le covid, 47 cas par jour sur 1.4 milliard d'hab, faudrait ne pas avoir de chance… Je suis aussi doublement vacciné, incroyable hein.

Que la Chine ait bien mieux géré cette épidémie que la France est un fait.
Si tes "priorités politiques" t'empêche de regarder ce qui se fait de bien ailleurs, c'est bien dommage. Il y a un tas (pas toutes cela-dit) de mesures prises en Chine qui auraient pu être appliquées en France, avec une réelle efficatité sur cette pandémie, et sans rogner sur les libertés fondamentales dont la France est (était) porte-drapeau. Ce laissez-passer pour aller au resto ou au supermarché, ça fait bien rire les chinois qui m'en parlent : "finalement la France est pire que la Chine".
M'enfin bref… que par principe la France ne regarde pas se qui se fait ailleurs, qu'elle continue à se regarder le nombril, divise son peuple, sombre économiquement, … et que ça t'aille bien comme ça, tant mieux pour toi, bisous.

quand la Chine te tire dessus si tu oses mettre un pied dehors dans ce même cas.

ha ? Depuis quand ? Pas de couvre-feu non plus en Chine.
Je sors souvent la nuit, je n'ai jamais vu quelqu'un se faire tirer dessus. Je suis allé me faire un petit 宵夜 hier soir (petite collation : genre barbecue), je suis rentré vers deux heures du mat, et je n'étais pas le seul, ce genre de petite collation tard le soir, c'est culturel ici.
Bref, il me semble que tu es plein d'a priori sur la vie en Chine, un petit voyage te ferait découvrir un autre mode de vie (sauf qu'en ce moment c'est mal-barré pour le voyage).

tu as des préférences de régime politique, soit, n'hésite pas à donner l'image complète, donc, sois-en fier, dans son ensemble et pas une petite partie affichage!

Pensées primaires, voire primitives…
J'ai des préférences politiques (comme tout un chacun) qui ne sont d'ailleurs pas en accord avec celle du PCC chinois, et alors ? La Chine n'est pas une démocratie, certes, et parce que la Chine est hyper-capitaliste (ceux qui pensent que la Chine est communiste, faut arrêter de vivre en 1960), faudrait ne pas regarder ce qu'ils ont fait de judicieux contre cette épidémie ? Si les politiques français pensent comme toi, pas étonnant que la France en soit dans cet état.

New-York tape fort, et hop vaccination obligatoire pour dîner

Chérie ça va moinser… car toutes les vérités ne sont pas bonnes à dire :

Entre la France et les US, et la tendance à généraliser ça un peu partout, je vais finir par croire que la Chine est le pays des libertés… un comble, non ?
En Chine, pas de pass sanitaire, pas d'obligation vaccinale, pas de port du masque obligatoire (sauf dans les transports en commun), bref un vie quasiment "comme avant" depuis mai 2020, et l'économie qui roule.

Aujourd'hui 47 cas sur 1.4 milliard… Si tous les pays avaient pris les mêmes mesures, ce virus serait déjà du passé. Est-ce qu'au bout d'un moment il pourrait arriver que les gouvernements prennent en modèle ce qui marche bien ailleurs ? Ou il y a des intérêts particuliers à ne pas le faire ? Bouh, le complotiste ! mais vu d'ici tant de (fausse ?) incompétence, ça pose question quand même.

Merci, c'est en effet prévu pour la v1.4 qui est sur le métier, car il n'est pas impossible qu'on parte d'un apache avec des fichiers de config qui merdouillent.

Le script évolue en fonction des choses que je note en lisant la doc complète d'Apache (je vais en avoir pour un moment, mais ça avance et j'apprends plein de trucs), et les remarques qu'on me fait à droite à gauche.

Je vais chipoter, mais déjà, je trouve qu’écrire  != c’est illisible.

fr.php.net, fonction readdir

Je cite :

if ($handle = opendir('/chemin/vers/fichiers')) {
    echo "Gestionnaire du dossier : $handle\n";
    echo "Entrées :\n";

    /* Ceci est la façon correcte de traverser un dossier. */
    while (false !== ($entry = readdir($handle))) {
        echo "$entry\n";
    }

    ...

    closedir($handle);
}
?>

Ca doit aussi être des gars qui font du PHP depuis 10 ans et qui n'ont pas su évoluer.

system("pgrep -f 'apache|httpd'") // Une liste de PID (un par ligne)

Je n'ai pas caché que c'est codé avec des partis pris, dont celui de limiter au maximum les dépendances. C'est dans le journal. Donc pas de pgrep.

Le seul changement qui frappe yeux est le closedir($h2); mal placé.
Mais comment arriver à ce type d'erreur ? Car le code ne s'écrit pas linéairement.
En général tu commences par :

if ($h2 = @opendir("/proc/$file1/fd")) {
}

puis tu remplis le niveau suivant :

if ($h2 = @opendir("/proc/$file1/fd")) {
    while (false !== ($file2 = readdir($h2))) {
    }
    closedir($h2);
}

et ensuite tu remplis le while.
Bref, c'est difficile d'avoir le closedir mal placé, sauf à coder avec un taux d'alcoolémie élevé.

J'ai l'impression qu'on est en train d'enculer des mouches là.
Prêcher les "bonnes" pratiques sans donner d'exemples clairs n'est déjà pas très utile.
Et puisque visiblement la lisibilité d'un code n'est pas quelque chose d'universel, on ne tombera pas tous d'accord sur tout. Par exemple dire que "on est sur un cas pathologique où les conditions sont dans des if alors qu'ils pourraient être dans les while", je trouve personnellement :

while (false !== ($file1 = readdir($h1)) || ! $found) {
    ...
}

moins clair que :

while (false !== ($file1 = readdir($h1))) {
    if (! $found) {
        ...
    }
}

J'aurais choisi la première option si les performances étaient un point critique, ce qui n'est pas du tout le cas ici. Que le script se termine 0.000003 secondes plus tôt n'a aucun intérêt.
On pourrait certes utiliser un break 2; (vu que deux while sont imbriqués), mais j'assume le choix de ne jamais utiliser ce truc.

De toute façon, c'est un bloc qui cherche le pid d'Apache et l'affiche (ou dit qu'il ne le trouve pas). C'est clair et tellement simple qu'un gars qui apprend PHP depuis une semaine serait parfaitement capable de le comprendre au premier coup d'oeil. Et comme ça fait le job, ce n'est pas là-dessus que je vais gaspiller du temps.

J'aurais largement préféré qu'on me fasse des retours sur les problèmes rencontrés sur des architectures que je n'ai pas pu tester ou sur les paramètres particuliers d'Apache à surveiller, plutôt qu'entamer un débat sur "Faut-il coder avec moins de 3 indentations ?"

PS : Fut un temps où je développais sur AS/400 en GAP3, une ligne de code = une carte perforée, donc pas d'indentation possible, ce qui n'empêchait pas d'imbriquer de nombreuses portions de code. Niveau lisibilité, c'était autre chose… certains devs imprimaient les codes et dessinaient des accolades pour trouver les portions de code concernées.

Bien que je ne sois pas d'accord sur le fond, je t’ai pertinenté parce que j'estime que ton point de vue est tout à fait légitime, je ne pense pas que ça vaille d'être moinssé.

C'est tout à ton honneur, car hélas beaucoup confondent "pertinent/inutile" et "d'accord/pas d'accord", ce qui nuit souvent à l'expression de la diversité des opinions.

Toutes tes remarques sur la façon de coder sont légitimes et pertinentes.
Sur ma résistance au changement, en fait j'accepte bien volontiers d'apprendre de nouvelles choses, d'évoluer, de m'adapter… mais force m'est de reconnaître que plus on vieillit, plus c'est difficile et lent.
Pour prendre un exemple en dehors de l'informatique, je vis en Chine depuis quelques années, donc je constate que lors de l'apprentissage du chinois, c'est plus difficile de retenir tous les nouveaux mots, tous les sinogrammes et toutes les expressions qu'à vingt ans, le cerveau n'est plus aussi souple pour s'adapter rapidement à la façon de tourner les phrases, etc.
Ca ne veut pas dire que je n'y arrive pas, juste qu'il faut plus de temps et y consacrer plus d'énergie.
Pour revenir au code, un autre facteur entre en jeu : quand tu as une façon de faire qui marche bien, qui a fait ses preuves (des ERP que j'ai codé il y a 20 ans tournent toujours et d'autres devs les font évoluer encore aujourd'hui), tu as plus de mal à changer pour utiliser une méthode qui à tes yeux présente davantage d'inconnues, avec moins de recul personnel.

Mais dans le cadre de cet outil, tout ça n'est pas bien grave, car c'est libre !
Ceux qui souhaitent le même type d'outil codé d'une autre façon (ou dans un autre langage), sont libres aussi de le forker, ou juste de s'en inspirer. Je n'y vois pas d'inconvénients, au contraire.
Et puis finalement, puisque c'est du libre fait sur mon temps libre, je le fais aussi comme j'aime le faire, tant qu'à faire.

À certains endroits ton code arrive à des niveau de 5 ou 6 indentations successives (entre divers if, while et foreach), ce qui rend le code très profond, et plus difficile à lire. Le cerveau humain est assez bête il aime lire de façon linéaire, et le découpage en fonctions aux endroits opportuns créé une encapsulation qui permet aux algorithmes importants d'évoluer à niveau plus haut ce qui leur donne plus de sémantique et moins de détails techniques, et d'être plus lisibles, car ça les rend plus linéaires.

Heu… 5 ou 6 indentations, mouais, bof, c'est quand même super banal.
Tant qu'il y a une rigueur dans l'indentation (toujours une tabulation, ou toujours 4 espaces… bref un choix constant) et que l'éditeur est un tant soit peu correct (j'utilise Geany qui est assez bien pour ça), ça reste très clair.
J'avais en mémoire un cas où j'avais indenté comme pas possible, du coup je suis allé vérifier : j'avais en 2003 codé un serveur smtp en PHP genre postfix, et qui gère encore mes mails aujourd'hui. J'avais du monter à 23 niveaux d'indentation. C'est certes un cas particulier, mais pas non plus difficile à lire pour autant.

Pour ce qui est des fonctions, si tu jettes un oeil au script apache2buddy.pl dont je me suis légèrement inspiré, tu verras que c'est blindé de fonctions … qui ne sont appelées qu'une seule fois. Et comme en plus elles sont dans n'importe quel ordre, pour suivre le fil du programme, faut sans arrêt faire des sauts d'un bout à l'autre du script.
Pas vraiment pratique à lire, ni linéaire pour le coup.

J'avoue que je code avec des pratiques qui ne sont sans doute pas celles qui sont utilisées par la majorité des devs, mais ça fonctionne, c'est au moins ça. Et puis à mon âge, il y a une certaine résistance naturelle au changement  ;-)

Merci pour tes remarques et le temps passé que tu as passé sur le code.

Oui, c'est écrit en procédural, à l'ancienne. Le faire en objet, pourquoi pas, mais il n'y a pas vraiment d'intérêt dans ce cas-ci. Et puis comme ça c'est facile à suivre : ce qui sort à l'écran est relativement proportionnel au code, donc facile de trouver la partie du code qui affiche telle ou telle ligne.

Pour les display("[..] foo bar");, je trouve plus lisible de les avoir comme ça plutôt que d'avoir 4 fonctions display_ok("foo bar");, display_alert("foo bar"); …
Mais la lisibilité, c'est sans doute quelque chose d'assez relatif, variable d'une personne à l'autre.

J'avoue que je n'ai pas compris le truc qui éviterait les readdir(), si tu peux détailler (idéalement avec un exemple) … ça m'intéresse.

Pour les shell_exec(), il n'y a pas d'entrées utilisateur, pas de noms bizarres, donc j'ai en effet fait l'impasse sur les escapeshellarg(), fainéant que je suis.

Pour les regex, j'en ai parlé parce que ce script est pour moi un peu l'exception qui confirmerait ma règle (je code principalement des sites web). Je suis d'accord avec toi que dans le cas présent, l'usage de regex pourrait alléger le code, mais comme je n'ai pas l'habitude d'en écrire… ben voilà le résultat.

Les seuls tests hardcodés pour les threads, c'est ThreadsPerChild :
1- test si < 20, parce que moins de threads par process, c'est limiter le partage des allocations mémoire, ce qui est justement tout l'intérêt des threads (avec la vitesse de création par rapport à un fork de processus).
2- test si > 20000, qui est une valeur très très haute (valeur par defaut : 25). Confier 20000 threads à un seul processus, ça me fait penser à cette citation : "Celui qui avale une noix de coco entière fait confiance à son anus." Que le processus merdoie et c'est 20000 threads qui partent en sucette. Il serait probablement plus sage de réduire le nombre de threads et augmenter le nombre de processus. Mais 20000 est pifométrique, je suis prêt à changer pour une autre valeur s'il y a un retour d'expérience qui va dans ce sens.
Pour les MinSpareThreads et MaxSpareThreads, c'est fonction de la quantité de RAM et de l'activation d'HTTP/2.
Globalement, ce n'est pas évident de déterminer des seuils ou des valeurs adéquates pour un certain nombre de paramètres en se basant uniquement sur les données que le script peut choper dans mod_status et mod_info. Et puis il y a aussi une très grande diversité dans les uages d'Apache qui complique les choses.

Tu as tout bien compris : c'est un plaisir de le faire, et j'espère que ça aidera avant tout les gens qui ne maîtrisent pas du tout Apache. Les pros d'Apache (que je ne suis pas, d'ailleurs) n'y trouveront sans doute pas leur compte, mais je suis preneur de leurs remarques, comme des tiennes.

La très grande majorité commentaires "négativés" ne sont pas polémiques, ils reflètent simplement des opinions minoritaires que certains utilisateurs n'aiment pas ou qui ne les intéressent pas.

Je trouverais bien que par défaut on voit tous les commentaires jusqu'à -5, car il arrive souvent que les optinions minoritaires soient aussi intéressantes, mais que par malchance des utilisateurs n'ayant pas trouvé ce commentaire intéressant soient passés avant ceux qui pourraient le trouver intéressant. Du coup, être masqué ne donne pas la chance à ce commentaire d'être sauvé. Un commentaire à -10, lui, mérite probablement d'être masqué.

Alternative : laisser un délai entre l'obtention d'une note négative et le masquage (par exemple un jour), histoire de lui laisser une chance de revenir en positif.

Alternative bis : mixer les deux. Laisser visible si supérieur à -5 pendant un jour, masquer si pas redevenu positif.

Alternative ter : nan, j'en ai pas.

Dans la mesure ou il y a des pays qui ont encore accès aux vaccins, je pense que ce point est totalement gratuit et non fondé.

Pfizer est une entreprise qui, comme les autres entreprises, se doit de tenir compte du stock existant avant de lancer une nouvelle formule. En quoi est-ce un point totalement gratuit et non fondé ? C'est le B-A-BA de la gestion de stock en entreprise.

Je continue de croire que si Macron avait dit "on va donner notre stock de vaccin à XXX", les mêmes en train de râler contre le passe sanitaire (eg, le RN parmi tant d'autres) serait déjà en train de dire qu'on devrait garder ça pour les français.

Qu'est-ce que Macron vient faire là-dedans ? A moins que tu ne penses qu'il y ait un lien entre les stocks d'un vaccin ancienne-formule (qui, allons dans l'hypothétique jusqu'au bout, serait moins efficace qu'annoncé contre le variant delta) et ses récentes allocutions. On peut discuter de tout, donc pourquoi pas, mais moi je ne parlais que des stocks de Pfizer. La gestion du stock de vaccin par le gouvernement, je ne sais pas s'il y en a, un peu, beaucoup, passionnément, à la folie, ou pas du tout.

Ensuite, vu les conditions de conservation, je ne serait pas étonné que ça soit logistiquement complexe de conserver des stocks. À un moment, si ça coûte plus cher de garder les choses que le bénéfice de vendre les stocks, c'est logique de détruire.

Le vaccin de pfizer (c'est quasi le seul utilisé en France et ça on peut légitimement se demander pourquoi) n'est pas le plus facile à stocker, mais le but est justement de ne pas les stocker, mais de les utiliser en totalité avant de passer à la nouvelle formule.

Merci, j'en étais resté au bon vieux &nbsp; en HTML, on ne peut pas le louper, celui là.
L'interpréteur PHP pourrait donc considérer ce AltGr+espace comme un espace si en dehors d'une chaine de caractères, mais c'est peut-être plus difficile à faire qu'à dire.
Et puis je n'utilise plus de clavier français depuis des années, du coup je n'ai plus ce problème.

Ca me rappelle la fois où j'ai cherché comme un con pendant un quart d'heure pourquoi un script PHP indiquait une erreur de syntaxe alors que la ligne concernée me paraissait tout à fait valide.
Comme c'était un bon gros IF avec une condition multiple, une ligne assez balaise, j'ai bien lu le truc au mois 20 fois, fait quelques modifs, simplifié la condition, … toujours pareil.
En désespoir de cause, je dérange le collègue pour qu'il vienne jeter un oeil, il regarde, ne comprend pas non plus pourquoi ça merde, et là on se regarde comme des cons, on se croit passés dans la 4ème dimension.
En désespoir de cause, je commente la ligne et la réécrit entièrement en dessous, à l'identique … et ça marche. WTF !?
Finalement j'ai trouvé le pourquoi du comment : en tapant vite sur un clavier français (à l'époque), l'espace avant l'accolade avec aussi bénéficié du AltGr. Donc à l'écran j'avais un bel espace qui n'en était pas un, c'était en réalité un AltGr+espace que l'interpréteur PHP ne considère pas comme un espace (à tort ou à raison, en fait je ne vois pas bien l'utilité qu'un caractère AltGr+espace pourrait avoir, mais il y en a peut-être une).
Bref, depuis je ne fais plus 100% confiance à ce que je vois.

Mais passer du changement de "formule" à la production de centaines de millions de doses est sans doute une autre paire de manches.

Non, mais se débarrasser des stocks existants avant d'écouler une nouvelle formule est indispensable économiquement (faut pas gâcher de la si belle marchandise, voyons)