regexpr "variables" ?

[kurtz_le_pirate]

bonjour,


soit la ligne de donnees :
<Auteur><Larry Wall><Developpeurs><The Perl Foundation>

la regexpr /<(.*?)><(.*?)><(.*?)><(.*?)>/ capture bien les 4 "elements".
la regexpr /<(.*?)><(.*?)><(.*?)>/ capture bien les 3 "elements".
donc s'il y a moins de mofifs de recheche que de donnees, cela fonctionne.


à l'inverse, si on applique 5 motifs /<(.*?)><(.*?)><(.*?)><(.*?)><(.*?)>/
et qui n'y a que 4 elements dans les donnees, je pensais que les $1 à $4
seraient remplis et que $5 serait à vide, ou undef, ou ... mais non, il n'y
a *aucune* capture.


je rève peut être, mais existe-t-il un moyen pour avoir un nombre "variable"
de motifs ?

[luc2]

je pensais que les $1 à $4 seraient remplis et que $5 serait à vide,
ou undef, ou ... mais non, il n'y a *aucune* capture.

crame !

je rève peut être, mais existe-t-il un moyen pour avoir un nombre
"variable" de motifs ?

la botte supreme de la grande ourse :

my @captures = $la_chaine =~ /<([^>]*)>/g;

[Marc Espie]

Post by luc2

je pensais que les $1 à $4 seraient remplis et que $5 serait à vide,
ou undef, ou ... mais non, il n'y a *aucune* capture.

crame !

je rève peut être, mais existe-t-il un moyen pour avoir un nombre
"variable" de motifs ?

Visiblement, tu ne connais pas *?
De ce point de vue, c'est une regression par rapport au post initial.

Visiblement egalement, aucun de vous n'a lu en detail la doc des regexp,
qui pourtant explique bien que n'importe quel caractere bizarre peut
(aujourd'hui ou demain) avoir une semantique particuliere, et donc qu'il
*faut* user abondamment de \...

my @captures = $la_chaine =~ /\<(.*?)\>/g;

Notons que c'est pas forcement genial parce que tout ce qui traine au milieu
va etre ignore, genre: bruit<valeur>bruit<valeur2>bruit

Mais ca par contre, je ne vois pas de facon simple de gerer avec juste de la
regexp...

On peut facilement couper avec split:
my @captures = split /(?<=\>)(?=\<)/, $chaine;
et ensuite verifier que chaque capture marche.
@captures = map {/^\<([^>]*)\>$/ or die "Badly formed string: $chaine ($_)"; $1; } @captures;

[luc2]

Post by Marc Espie
Visiblement, tu ne connais pas *?
...
Visiblement egalement, aucun de vous n'a lu en detail la doc des regexp,
...

visiblement, tu t'prends pas pour la moitie d'un naze toi :)

[Olivier Miakinen]

Post by Marc Espie
Visiblement, tu ne connais pas *?
De ce point de vue, c'est une regression par rapport au post initial.
Visiblement egalement, aucun de vous n'a lu en detail la doc des regexp,
qui pourtant explique bien que n'importe quel caractere bizarre peut
(aujourd'hui ou demain) avoir une semantique particuliere, et donc qu'il
*faut* user abondamment de \...

Ça aussi ça me semble être une régression : j'aurais préféré que les
options à venir se contentent de constructions du style (?#...) (où
« # » représente un caractère non encore utilisé), ou bien justement
utilisent le \ pour les nouvelles constructions.

Mébon, c'est comme ça, il faut faire avec.

Post by Marc Espie
Notons que c'est pas forcement genial parce que tout ce qui traine au milieu
va etre ignore, genre: bruit<valeur>bruit<valeur2>bruit
Mais ca par contre, je ne vois pas de facon simple de gerer avec juste de la
regexp...

Peut-être en deux étapes.

Commencer par récupérer la plus longue chaîne possible sans bruit :
/\< ( [^\<\>] | \>\< )* \>/x

Puis appliquer la regexp simple sur le résultat :
/\<(.*?)\>/g

[Jerome Quelin]

Post by Marc Espie
Visiblement egalement, aucun de vous n'a lu en detail la doc des regexp,

visiblement surtout, aucun de vous ne sait qu'il ne faut pas utiliser les
regexp pour parser du xml.

perldoc -q xml

jérôme

[Marc Espie]

Post by Jerome Quelin

Post by Marc Espie
Visiblement egalement, aucun de vous n'a lu en detail la doc des regexp,

visiblement surtout, aucun de vous ne sait qu'il ne faut pas utiliser les
regexp pour parser du xml.
perldoc -q xml

L'exemple donné n'est pas techniquement du xml... aucun tag de fin, par
exemple.

L'air de rien, c'est une des debilites de la tendance "tout xml" des neuneus
bouffeurs de java: faut des outils specifiques, ca se parse pas a coups de
regexps... et toutes les bibliotheques existantes sont trouees, de facon
plus ou moins subtiles (la plupart supposent que les fichiers consideres
sont "gentils", et donc ne prennent pas de precaution particuliere pour
limiter les niveaux de recursion, quand c'est pas carrement la partie utf8
qui cree des buffer overflows...)

[Olivier Miakinen]

Bonjour,

Post by Jerome Quelin
visiblement surtout, aucun de vous ne sait qu'il ne faut pas utiliser les
regexp pour parser du xml.

Je suis le premier à dire que les regexp ne peuvent pas tout, et qu'il
faut savoir utiliser un vrai parseur dès que ça devient un tant soit peu
complexe.

Mais je ne vois pas ce qui te fait dire, à partir de la seule ligne de
données « <Auteur><Larry Wall><Developpeurs><The Perl Foundation> »,
qu'il s'agirait d'un document XML -- sans même parler de complexité.

Cordialement,

[Jerome Quelin]

Post by Olivier Miakinen

Post by Jerome Quelin
visiblement surtout, aucun de vous ne sait qu'il ne faut pas utiliser les
regexp pour parser du xml.

Je suis le premier à dire que les regexp ne peuvent pas tout, et qu'il
faut savoir utiliser un vrai parseur dès que ça devient un tant soit peu
complexe.
Mais je ne vois pas ce qui te fait dire, à partir de la seule ligne de
données « <Auteur><Larry Wall><Developpeurs><The Perl Foundation> »,
qu'il s'agirait d'un document XML -- sans même parler de complexité.

parce que tout code monstrueux n'est qu'un petit script qui n'a pas-besoin-
d'un-vrai-parser-parce-que-regarde-les-données-sont-super-simples-et-promis-
ce-ne-sera-jamais-plus-compliqué-que-cela qui a évolué et accumulé des tas
de modifs pour prendre en compte de nouveaux cas dans les données en entrée.

et quand on se rend compte que le script est monstrueux, il est trop tard
pour le reprendre sainement, car on aura peur de tout casser et qu'après
tout, ça marche comme ça.

d'autre part, sur du markup avec des <>, la plupart du temps c'est du xml.
si c'est juste des valeurs comme ça sur une seule ligne, le standard c'est
csv. donc je ne pense pas trop m'avancer en disant que l'exemple original
est tiré d'un document xml.

jérôme

[Xavier]

Post by Jerome Quelin
parce que tout code monstrueux n'est qu'un petit script qui n'a pas-besoin-
d'un-vrai-parser-parce-que-regarde-les-données-sont-super-simples-et-promis-
ce-ne-sera-jamais-plus-compliqué-que-cela qui a évolué et accumulé des tas
de modifs pour prendre en compte de nouveaux cas dans les données en entrée.
et quand on se rend compte que le script est monstrueux, il est trop tard
pour le reprendre sainement, car on aura peur de tout casser et qu'après
tout, ça marche comme ça.

Ca sent le vécu :-) Mais je crois qu'on a tous vécu ça à un moment où à
un autre...

[Nicolas George]

Jerome Quelin wrote in message

Post by Jerome Quelin
csv. donc je ne pense pas trop m'avancer en disant que l'exemple original
est tiré d'un document xml.

Il suffit de lire l'exemple original pour voir que non : ce n'est pas du
XML bien formé.

[Marc Espie]

Post by Jerome Quelin

Post by Jerome Quelin
visiblement surtout, aucun de vous ne sait qu'il ne faut pas utiliser les
regexp pour parser du xml.

Je suis le premier à dire que les regexp ne peuvent pas tout, et qu'il
faut savoir utiliser un vrai parseur dÚs que ça devient un tant soit peu
complexe.
Mais je ne vois pas ce qui te fait dire, à partir de la seule ligne de
données « <Auteur><Larry Wall><Developpeurs><The Perl Foundation> »,
qu'il s'agirait d'un document XML -- sans même parler de complexité.

parce que tout code monstrueux n'est qu'un petit script qui n'a pas-besoin-
d'un-vrai-parser-parce-que-regarde-les-données-sont-super-simples-et-promis-
ce-ne-sera-jamais-plus-compliqué-que-cela qui a évolué et accumulé des tas
de modifs pour prendre en compte de nouveaux cas dans les données en entrée.

Bof, bof, bof. Quelle que soit la question, xml n'est jamais la bonne reponse.
La reponse facile, oui. Mais la bonne, non.

[Nicolas George]

Post by Marc Espie
Bof, bof, bof. Quelle que soit la question, xml n'est jamais la bonne reponse.
La reponse facile, oui. Mais la bonne, non.

La bonne réponse est souvent la réponse facile, pourtant.

XML a l'avantage d'avoir un mécanisme d'échappement complet, fiable et
régulier pour les chaînes de caractères (donc on ne se demande pas s'il faut
écrire \", ou '' ou que sais-je), c'est déjà un plus considérable par
rapport à la plupart des formats bricolés vite fait.

[Olivier Miakinen]

Post by Jerome Quelin

Post by Olivier Miakinen
Mais je ne vois pas ce qui te fait dire, à partir de la seule ligne de
données « <Auteur><Larry Wall><Developpeurs><The Perl Foundation> »,
qu'il s'agirait d'un document XML -- sans même parler de complexité.

parce que tout code monstrueux n'est qu'un petit script qui n'a pas-besoin-
d'un-vrai-parser-parce-que-regarde-les-données-sont-super-simples-et-promis-
ce-ne-sera-jamais-plus-compliqué-que-cela qui a évolué et accumulé des tas
de modifs pour prendre en compte de nouveaux cas dans les données en entrée.

Comme te l'a répondu Xavier, ça sent le vécu. ;-)

Mais...

Post by Jerome Quelin
d'autre part, sur du markup avec des <>, la plupart du temps c'est du xml.

... comme l'a écrit Nicolas, ce n'est pas du XML bien formé.

Pour que c'en soit, au lieu de :
<Auteur><Larry Wall><Developpeurs><The Perl Foundation>
il aurait fallu par exemple :
<Auteur>Larry Wall</Auteur><Developpeurs>The Perl
Foundation</Developpeurs>

Et dans ce cas, tu peux être certain que j'aurais déconseillé les regexp.

Cordialement,

[Olivier Miakinen]

Bonjour,

Je fais suivre ta question et ma réponse vers fr.comp.lang.regexp car
elles devraient intéresser tous les utilisateurs des regexp et pas
seulement ceux de Perl.

Post by kurtz_le_pirate
<Auteur><Larry Wall><Developpeurs><The Perl Foundation>
la regexpr /<(.*?)><(.*?)><(.*?)><(.*?)>/ capture bien les 4 "elements".
la regexpr /<(.*?)><(.*?)><(.*?)>/ capture bien les 3 "elements".
donc s'il y a moins de mofifs de recheche que de donnees, cela fonctionne.
à l'inverse, si on applique 5 motifs /<(.*?)><(.*?)><(.*?)><(.*?)><(.*?)>/
et qui n'y a que 4 elements dans les donnees, je pensais que les $1 à $4
seraient remplis et que $5 serait à vide, ou undef, ou ... mais non, il n'y
a *aucune* capture.

Dans PCRE il existe une option PCRE_PARTIAL permettant de vérifier une
regexp sur une chaîne incomplète, mais celle-ci n'existe pas dans Perl.

Post by kurtz_le_pirate
je rève peut être, mais existe-t-il un moyen pour avoir un nombre "variable"
de motifs ?

Oui : /<(.*?)><(.*?)><(.*?)><(.*?)>(?:<(.*?)>)?/

Maintenant, si tu veux que ça soit variable à l'infini (un truc qui
créerait autant de $n que nécessaire), je ne crois pas que ça soit
possible.

Cordialement,