Ignatz Ledebur a écrit 427 commentaires

En fait il n'y a aucune expression régulière dans ce code. :)

FNR et NR correspondent respectivement au nombre de lignes (on parle d'enregistrements en fait, car en changeant la valeur de RS, on peut acquérir un fichier en d'autres portions qu'en lignes) lues dans le fichier traité et dans l'ensemble des fichiers. Ici ça sert à traiter séparément le premier fichier "mydomain" (d'où le next en fin le bloc) : je découpe chaque ligne dans le tableau t en prenant la virgule comme séparation de champ, j'enregistre le premier champ comme clé dans le hash CSV, puis la ligne dans son aspect définitif comme valeur dans LINE.

Le deuxième bloc va donc traiter le fichier "cvs". Il prend chaque premier champ et vérifie si celui-ci est une clé dans CVS. Si c'est le cas il émet un point-virgule. Ensuite et dans tous les cas, il imprime la ligne.

Le dernier bloc END est spécial et exécuté en fin de traitement. Ici il restaure le contenu de LINE, c'est à dire le contenu de "mydomain" formaté comme il se doit.

Si tu veux en apprendre plus sur AWK, qui a été une grande source d'inspiration pour Perl, je te conseille le Manuel de l'implémentation GNU, très complet, et la page POSIX, qui fera une bonne référence pour la programmation quotidienne. Si tu comptes te lancer dans la programmation shell, apprendre AWK est vraiment un bon investissement qui permet de coder rapidement des petits filtres sur mesure très efficaces.

Si tes codes sont si petits, ce serait bien plus simple de résoudre ton problème si tu les postais ici. Parce que là, à part te dire de mettre chaque bout de code dans une fonction, on ne peut pas grand chose pour toi.

ça m'intéresserait de savoir depuis quand :-)

Depuis 1987, si on en croît le manuel de GAWK. C'est en tout cas disponible dans l'implémentation de Kernighan, qui reflète ce qui est décrit dans The AWK Programming Language.

Pour ce que je comprends, sortir Perl pour ça est un peu overkill. Un essai en AWK qui devrait te donner ce que je conçois être le résultat final (/tmp/csv dans le même ordre mais avec les entrées présentes dans mydomain.com précédées d'un ";", puis le contenu de mydomain.com avec par ligne une tabulation séparant le premier champ initial de la concaténation des deux autres) :

(FNR == NR) {
    split($0, t, ",")
    CSV[t[1]] # La clé de contrôle
    LINE[C++] = t[1]"\t"t[2]t[3]
    next
}   
($1 in CSV) { printf("%s", ";") }
{ print }
END {
    for (i=0; i<C; i++)
        print LINE[i]     
}

Pour exécuter, il suffit de lancer : awk -f ce_script.awk mydomain.com /tmp/csv. Le résultat sera envoyé sur la sortie standard que tu pourras rediriger vers n'importe quel fichier (plus prudent àmha que de bosser directement sur la base initiale).

Bien sûr, je n'ai pas testé plus que ça, et si tu n'es pas attaché à l'ordre des lignes, on peut optimiser. ;)

Dois-je en conclure qu'on n'a pas fini de parler de \x73\x79\x73\x74\x65\x6d\x64 ?

Donc le PHP a vraiment fonctionné principalement grâce à Windows + effet de mode.

Encore la marque de Redmond, j'aurais dû y penser ; ces gens-là, décidément, ne respectent rien. ;)

Merci à vous deux pour ces précisions.

À noter qu'avant l'entretien avec Larry Wall a eu lieu celui avec Ricardo Signes, l'actuelle « citrouille » (mainteneur en chef) de Perl 5, où l'on en apprend un peu plus sur le cycle de développement de celui-ci.

En tous les cas, ça fait bien plaisir de lire cette petite dépêche sur Perl, langage plus très à la mode mais qui reste mon indéboulonnable favori parmi les langages de scripts (d'ailleurs, je n'ai jamais compris comment PHP l'avait détrôné pour le CGI, si quelqu'un a un pointeur ou une explication, je suis preneur), et qui continue d'évoluer tranquillement dans son coin.

Il s'agit ici des espoirs politiques du net, de technique il n'est quasiment pas question en fait. L'entretien porte sur les changements sociétaux qu'on pouvait espérer du fait que n'importe qui pouvait désormais, grâce au réseau, diffuser telle quelle sa parole dans l'espace public.

Le bilan semble, selon les intervenants, quelque peu en demi-teinte. Si le réseau est devenu incontournable et bouscule effectivement les détenteurs du pouvoir, aujourd'hui plus que jamais prêts à tout pour en prendre le contrôle, l'émergence très problématiques de centres (facebook, google et consorts) en son sein n'avait en revanche pas été anticipée.

À noter une intéressante remarque de Benjamin Bayart, qui lie la puissance d'attraction de ces nouveaux centres à la volonté du grand nombre d'avoir du « tout facile, tout maintenant, en un clic ». À relier, peut-être, avec ce qu'on a vu de l'évolution de la bureautique libre cette dernière décennie, où l'horizon indépassable semble avoir été d'obtenir un MS-Windows ou un OSX libres, avec çà et là quelques différenciations mais sans jamais chercher à rompre avec la facilité telle que comprise et mise en pratique dans ces environnements (mes 2cts).

J'entends bien. En fait il semble que javascript soit un pré-requis (section 10 de la présentation), de même que la CSS. C'est un choix, mais qui reste assez curieux quand il existe déjà des solutions de rendu purement HTML bien établies (par exemple, en enlevant juste la CSS, on perd les numéros des notes en bas de page gérées via des div, ce qui ne serait pas arrivé en passant par une liste ordonnée comme cela se pratique classiquement).

Je me trompe peut-être, mais ça donne l'impression d'avoir été conçu selon une logique avant tout visuelle, WYSIWYG au lieu de WYSIWYM.

C'est pas justement le but d'EPUB 3 de permettre la description de documents techniques/mathématiques via un sous-ensemble d'HTML5 ? Ça a certes du mal à prendre (EPUB 2 semble suffire à la majorité des publications), mais on peut au moins espérer que le statut de standard lui permette à terme d'être lisible sur tout un tas d'appareils sans devoir passer par un convertisseur.

D'autant que certains choix de mise en forme me laisse dubitatif : à quoi bon un span code (clé de pur style) quand l'élément code est disponible depuis belle lurette ? Là, sans javascript, le rendu des blocs de code est juste dégoûtant, alors qu'un pre immédiatement suivi d'un code aurait eu le même résultat mais compréhensible par n'importe quel navigateur.

Ben oui, sinon tu ne le verrais pas ;-).

Tout à fait, loin de moi l'idée d'en faire le reproche à flan.

PS : est l'UTF-8 était toujours HS pour vous deux, HS dans le sens où ce n'est pas le sujet sur les deux formes Unicode qui pose problème ;-).

Toujours pas. ;)

Un hors-sujet, c'est ce qui sort de l'énoncé du problème. Or, s'il avait effectivement existé un début de séquence UTF-8 magique permettant de « coller » deux ascii pour représenter un seul caractère (ce que je j'essaie de décrire dans mon premier message), on aurait bien eu deux codages possibles pour une même représentation, ce qui aurait été une bonne illustration du problème.

Pour être plus clair : si dans un devoir sur la respiration des cétacés tu traites (même savamment) de la reproduction des belettes en milieu péri-urbain, c'est un hors-sujet ; si tu commences par évoquer les branchies des baleines, c'est bien le sujet mais traité de manière absurde*. Dans les deux cas, on est d'accord que tu as tout faux (et pour ce qui est d'UTF-8, crois-moi j'en suis bien content), mais pas de la même manière.

* note que dans ce cas la question de savoir pourquoi alors les baleines sont obligées de remonter à la surface reste en elle-même pertinente, c'est juste une autre manière de gérer l'absurdité quand on est pas 100% sûr que c'en soit une mais qu'elle heurte ce qu'on croit savoir.

La code 96 est pour un signe indépendant.
Il n'y a pas de code en Latin-1 pour un signe dépendant, donc non, techniquement ce n'est pas possible, faute de code.

Ah oui, d'accord, là ça s'éclaire vraiment. En fait, j'avais à l'esprit le rendu (en sens inverse) qu'on obtient sur certains vieux logiciels quand ils doivent rendre du latin1 en ascii (où ê devient e^), mais on est dans une gamme de caractères dédiés (que du coup flan a rendu dans son premier commentaire avec le caractère 96 de l'ascii, ce qui m'a enduit d'erreur).

Tu parles du codage UTF-8 d'un caractère Unicode, il parle de deux points Unicode pour écrire un caractère accentué (donc deux foix le codage UTF-8).

Au final oui, mais dans son message initial, il a bien parlé d'UTF-8, ce qui m'a surpris par rapport à ce que je sais de cet encodage. Or, je ne prétends pas tout savoir, d'où ma demande de précisions au cas où j'aurais pu apprendre quelque chose.

Je n'ai jamais dit que ta question est HS

Excuse-moi, mais « Vous » dans un fil d'exactement deux messages, ça désigne les auteurs des deux messages. Tu aurais simplement pu dire « je crois qu'en fait il veut parler de points de code et pas d'octets », pas besoin de rentrer dans les gens en affirmant direct qu'ils ne disent pas ce qu'ils sont précisément en train de dire (un peu comme si moi j'avais commencé mon commentaire à flan par « c'est vraiment n'importe quoi ce que tu dis sur UTF-8, … » – mais, ça aussi, c'est pas comme si les gens ne t'avaient jamais fait remarquer cette attitude, mieux vaut donc lâcher définitivement l'affaire pour ce qui te concerne du point du vue de la convivialité).

Oui, en effet, j'ai mis UTF-8 au lieu d'Unicode

D'accord, je comprends mieux. Merci pour les précisions.

Le conflit n'existe pas en Latin-1

Techniquement, il pourrait, puisqu'au final ce n'est en fait pas une question de codage (on peut rendre les deux octets 101 et 96 ou bien le seul octet 232).

Euh… là c'est plutôt toi qui est HS, car justement je questionne strictement ce qui est dit à propos du codage, pas sur ce qui touche la collision des représentations (à ce niveau, le conflit resterait le même en Latin1, mais ça ne m'interrogerait pas, ou pas de la même manière). Tu as le droit de supposer que flan a utilisé improprement le terme « UTF-8 » en voulant dire « Unicode », ça ne rend pas pour autant ma question HS (même si effectivement, c'est une piste de réponse).

il faut savoir qu'en UTF-8, un même caractère peut être représenté de plusieurs façons (« è » peut être
stocké comme un « è » ou comme un « e + ` »)

Tu as de la doc là-dessus ? Je ne dis pas que c'est faux, mais c'est si contraire au fonctionnement d'UTF-8 et a priori d'un intérêt si marginal que ça me désarçonne un peu.

En UTF-8, la séquence codant un caractère sur plusieurs octets indique via les bits à 1 (au minimum 2) démarrant le premier de ceux-ci combien d'octets elle occupe, chacun des autres octets commençant ensuite par un bit à 1 suivi d'un bit à 0. Ça permet de toujours pouvoir se situer dans une chaîne (si tu as un premier bit à 1, tu sais que tu es sur un caractère codé sur plusieurs octets, si le bit suivant est à 0, tu sais que c'est un octet intermédiaire et qu'il faut donc aller dans les octets précédents pour retrouver le premier et pouvoir reconstituer toute la séquence). Là, avec ce que tu décris, il faudrait avoir un octet spécial 111???? suivi par deux octets sur 7 bits 0???????, ça casse tout.

De ce que je sais, systemd vire toute la couche shell pour la remplacer par des fichiers de config, c'est un gros changement dans l'interaction avec le système.

Le lien entre systemd et Windows, c'est beaucoup dû au fait qu'on ne sait pas s'il va finir par y avoir intégration au niveau des environnements de bureau. On voit déjà (cf. courriel de Lennart) que le but est d'avoir à terme une pile noyau/systemd/GNU comme base standard Linux (gérer Linux presque comme un BSD en fait), et il est encore bien difficile de savoir où ça va s'arrêter (on peut voir ça comme un problème de force de gravité, plus systemd deviendra massif dans la galaxie Linux, plus il sera pratique de se laisser reposer dessus).

Et puis il ne faut pas prendre les choses à l'envers : si tu veux un Linux « Windows Libre » alors tu es favorable à systemd qui est un pas vers la bonne direction (d'où la pertinence de la division autour du desktop), mais on peut être pour systemd sans que ce soit le cas, personne ne dit le contraire (le développeur de uselessd n'est probablement pas un pro-desktop, pourtant il part sur la base de systemd).

Perso, je pense que la division (en très grossier) « Windows libre » vs « informatique inspirée depuis la console » est pertinente, et tiraille depuis longtemps la communauté (je l'ai toujours sentie, mais c'est toujours plus facile de sentir les choses d'un point de vue minoritaire – ce qui au passage n'implique pas que l'autre côté soit incompétent en shell, c'est juste qu'on ne l'y envisage pas comme l'interface principale du système), même si c'est seulement maintenant que ça se mue en bataille rangée.

Maintenant, il est évident que l'informatique n'a plus grand chose à voir avec ce qu'elle était il y a dix ans, c'est aujourd'hui un truc vraiment énorme (il y en a vraiment partout, et ça ne va pas s'arrêter), probablement bien trop massif pour qu'il y ait quoi que ce soit de rationnel dans son évolution (probablement qu'il y a une part de simple résistance au changement, mais aussi de l'autre côté du changer pour coller au troupeau, ce qui est tout aussi humain et guère plus digne d'éloges).

• hack : expédient (« a big hack » == « un expédient grossier » )
• scope : champ d'application
• backend : soubassement

Je crois que la clé est dans le courriel de Lennart Poettering. Il ne cache pas que le but à terme est d'avoir une pile noyau/systemd/GNU comme socle du système Linux, ce qui va fatalement nécessiter, au fur et à mesure que les composants de base seront intégrés à systemd (syslog, la console, etc.), de coder/maintenir des alternatives, aboutissant lentement mais sûrement à élaborer deux piles de base distinctes (noyau/systemd/GNU et noyau/un tas d'outils indépendants/GNU).

Finalement, ce ne sera pas très différent de ce qui se fait sous BSD, où chaque projet, même s'il n'a pas beaucoup de ressources, maintient sa propre pile de base en reprenant/intégrant les fonctionnalités qui l'intéresse chez les autres. Je pense que, comme le suggère l'auteur original, le vrai problème des détracteurs de systemd est qu'actuellement ils savent qu'ils ne veulent pas de systemd sans savoir où ils veulent vraiment aller, (contrairement à ceux qui font systemd, qui ont de toute évidence les idées claires).

Il y a aussi le problème de la perméabilité des couches. Si on est quasi-sûr que Linus ne laissera jamais l'intégration noyau/systemd se faire, il se pourrait que dans les couches hautes les gros environnements de bureau cèdent à la tentation, auquel cas ce sera très compliqué pour la pile alternative (faire du bricolage pour avoir une pile qui fonctionne sans systemd quand une partie est prévue pour, ça risque de susciter beaucoup de frustration chez ceux qui tiennent à la propreté des implémentations).

Ma faute en plus… décidément.

Ils travaillent souvent sur des fonctionnalités destinées à la gestion des serveurs d'entreprise, à l'informatique dans les nuages, aux systèmes embarqués […] Ce sont des hackeurs, […]

Ça ne me paraît pas vraiment être le profil du ubuntero de base. Je pense que l'idée c'est qu'au sein du Libre s'affrontent deux tendances, celle qui veut une autre manière d'interagir avec les ordinateurs par rapport à ce qui ce fait chez Windows/OSX et celle qui pense que le Libre peut les concurrencer et les battre sur leur propre terrain. Quelle que soit l'option qu'on préfère, il y a besoin de développeurs compétents dans les trucs poilus.

Encore une…

s/ce sont les mainteneurs des distros qui porte/ce sont les mainteneurs des distros qui portent/

j'ai adoré l'expression très imagée « vous faire seppuku avec une roulette à pizza »

+1

Perso, ça m'a aussi évoqué Hara-kiri, dans lequel ils obligent le gars à s'ouvrir le ventre avec son sabre en bois. Comme quoi, le seppuku on en fait tout un plat, mais c'est juste une question d'outillage.

J'ai pas mal souffert sur ce passage (la traduction de « solve », en particulier). Dans la révision, je mettrais juste « qu'ils pensent être » pour s'économiser le « dont ».

Et puisqu'on en cause, j'ai eu un doute sur le sens de la parenthèse, je ne sais pas si ça veut dire « ils ont écrits certains de ces outils », ou bien « ces outils sont certains de ceux qu'ils ont écrits ». Dans le deuxième sens, ça pourrait sous-entendre qu'ils s'en sortent avec du gros hack perso mais pas une solution universellement déployable. Vraiment, je ne sais pas.