je développe un petit script qui doit récupérer le nom de l'expéditeur
d'un mail (du champ From:).
Mon gros souci vient des lignes du genre :
From: ?=ISO8859-1?Q?Fran=E7ois=?
Avec une expression régulière, je récupère correctement l'encodage en
$1, le mode utilisé (base64 B ou quoted printable Q) en $2 et le texte
lui-même en $3.
En gros, il faut transformer la chaîne $3 en caractères (split //, $3),
puis parcourir le tableau à la recherche d'un =, si on en trouve un,
agglomérer les deux caractères suivants et regarder si =~
/[0-9A-Fa-f][0-9A-Fa-f]?/ et le cas échéant faire un oct pour récupérer
le caractère sous forme d'un octet.
Maintenant, mon problème est le suivant : comment faire pour réinjecter
cet octet dans le tableau de caractères de sortie (en gros, je veux
rentrer dans ce tableau de chaînes de caractère une chaîne d'une lettre,
cette lettre étant représentée par l'octet trucmuche) ?
push @sortie, chr oct (truc); ne fonctionne pas car je suis en encodage
utf8. push @sortie, Encode::decode ($1, chr oct (truc)) ne fonctionne
évidemment pas plus puisque chr ne retourne rien de valable.
Ca peut etre effectivement complexe a faire coexister.
Chez les voisins (Open), j'ai dans les plans a moyen terme d'unifier un peu plus ca. Deja, on a aux 3/4 automatise la creation d'un port d'un module CPAN, et on doit avoir plus de 500 packages en rapport avec CPAN. Autant dire une enorme partie des trucs utiles.
L'intérêt de BSDPAN sur FreeBSD est de pouvoir installer (via 'cpan') des modules Perl non packagés ou packagés avec une version différente de celle qu'on veut. Ça crée des packages au vol et ça n'entre pas en conflit avec les vrais packages contenant des modules CPAN.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Wed, 28 May 2008 15:23:07 +0000 (UTC),
espie@lain.home (Marc Espie) écrivait (wrote):
In article <483d6e32$0$26597$426a74cc@news.free.fr>,
Vincent <10.50@free.fr> wrote:
je ne vois pas pourquoi NetBSD interdirait l'utilisation de la
commande 'cpan' et de tout ce qui va bien...
Ca peut etre effectivement complexe a faire coexister.
Chez les voisins (Open), j'ai dans les plans a moyen terme d'unifier un
peu plus ca. Deja, on a aux 3/4 automatise la creation d'un port d'un
module CPAN, et on doit avoir plus de 500 packages en rapport avec CPAN.
Autant dire une enorme partie des trucs utiles.
L'intérêt de BSDPAN sur FreeBSD est de pouvoir installer (via 'cpan')
des modules Perl non packagés ou packagés avec une version différente
de celle qu'on veut. Ça crée des packages au vol et ça n'entre pas en
conflit avec les vrais packages contenant des modules CPAN.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
Ca peut etre effectivement complexe a faire coexister.
Chez les voisins (Open), j'ai dans les plans a moyen terme d'unifier un peu plus ca. Deja, on a aux 3/4 automatise la creation d'un port d'un module CPAN, et on doit avoir plus de 500 packages en rapport avec CPAN. Autant dire une enorme partie des trucs utiles.
L'intérêt de BSDPAN sur FreeBSD est de pouvoir installer (via 'cpan') des modules Perl non packagés ou packagés avec une version différente de celle qu'on veut. Ça crée des packages au vol et ça n'entre pas en conflit avec les vrais packages contenant des modules CPAN.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Vincent (ex Elendir)
Chez les voisins (Open), j'ai dans les plans a moyen terme d'unifier un peu plus ca. Deja, on a aux 3/4 automatise la creation d'un port d'un module CPAN, et on doit avoir plus de 500 packages en rapport avec CPAN. Autant dire une enorme partie des trucs utiles.
Intéressant, il faut voir dans quelle mesure cela pourrait être transposé sur le PKGSRC de NetBSD.
V.
Chez les voisins (Open), j'ai dans les plans a moyen terme d'unifier un
peu plus ca. Deja, on a aux 3/4 automatise la creation d'un port d'un
module CPAN, et on doit avoir plus de 500 packages en rapport avec CPAN.
Autant dire une enorme partie des trucs utiles.
Intéressant, il faut voir dans quelle mesure cela pourrait être
transposé sur le PKGSRC de NetBSD.
Chez les voisins (Open), j'ai dans les plans a moyen terme d'unifier un peu plus ca. Deja, on a aux 3/4 automatise la creation d'un port d'un module CPAN, et on doit avoir plus de 500 packages en rapport avec CPAN. Autant dire une enorme partie des trucs utiles.
Intéressant, il faut voir dans quelle mesure cela pourrait être transposé sur le PKGSRC de NetBSD.