Salut,
 
J'utilise à outrance les regexp en perl.
J'ai été récemment confronté à un grave probleme :
 
J'ai changé de serveur et ma version de perl est donc passée de 5.8.8 à 5.10.0.
J'ai découvert que lors de cette upgrade, perl avait changé la donne quant à l'interprétation des regexp:
les règles ne sont plus les mêmes !!!
Résultat: toutes les sources à modifier !
 
Voila un exemple qui illustre une différence nette (parmi combien ?)

Dans l'ancienne version de perl (5.8.8), cela se comportait comme on peut l'imaginer:
Ca match tout en prenant le dernier PROUT s'il y en a plusieurs, en affichant donc "1246337632" dans mon exemple.
 
Mais dans le 5.10.0, ca ne matchera carrément plus ! le if est false !
 
Que l'on trouve cet exemple propre ou non, il y a tout de même un sacré problème !
Comment est-il possible que 2 versions de perl réagissent différemment sur un meme code ?
 
J'ai donc été amené à remettre mes sources en question et lorsque j'utilise la méthode suivante, ca match correctement :

NB: j'ai juste remplacé (.|\n) par [\S\s].
cela supprime une parenthèse, sympa lorsque le motif est énorme avec des \10 et des $11 ... surtout lorsqu'il faut modifier toutes ses sources depuis des années ...
 
 
Je me pose donc encore la question suivante, qui est l'objet de ce topic :
Que faut-il utiliser lorsqu'on veut matcher tout caractère, y compris \n ?
 
Après réflexion je pense que mon (.|\n) était très sale et stupide car utiliser un | pour un seul caractère n'est pas franchement approprié (meme si ca devrait fonctionner)
J'ai donc pensé à [\S\s]
 
Quelqu'un a-t-il une meilleure idée ?
Qu'utilisez vous personnellement ?
 
MERCI !

 
 
Vérifies qu'il n'y a pas de problème avec la version de perl sur ce serveur, car elle a l'air buggée:
 
J'ai la version 5.10.0 (build 1004 du 3 septembre 2008 de Active State)
 
J'ai créé un fichier test.txt avec:
 

2009-06-30_06:53:50 1246337630 0.0.0.0() test PROUT "bonjour tout le monde"
2009-06-30_06:53:50 1246337631 0.0.0.0() test PROUT "bonjour tout le monde"
2009-06-30_06:53:50 1246337632 0.0.0.0() test PROUT "bonjour tout le monde"

 
j'ai écrit en vitesse ce test:
 

#/usr/bin/perl
use warnings;
use strict;
 
 
open my $FILE, '<', "test.txt";
my $temp = join "", <$FILE>;
close $FILE;
 
if( $temp =~ /^((.|\n)*)\s(\d{10})\s+\S+\s+\S+\s+PROUT\s/i ){
   print("$3\n" );
 }

 
Et quand je lance le test, ça me donne bien "1246337632" comme résultat.
 
A+,

bon, alors en effet, je viens de faire le test et ca marche aussi chez moi.
Je n'aurais pas du simplifier mon exemple et prendre le cas réel !
 
Mais le cas réel est un fichier assez gros et un code assez gros aussi.
Je vais donc étudier ca pour comprendre à quel moment ca change entre mon cas réel et l'exemple.
Je reposte dès que j'ai un exemple simplifié qui fait le meme probleme. (c'est peut etre une question de taille de fichier... je vais voir ca)
 
Sinon, tu utiliserais quelle formule pour "tout caractère" ?
 
[\S\s] ca me parait pas mal mais ca reste encore sale je trouve à mon gout... mais j'ai pas vraiment d'autre idée...
 
merci !

Ca y est, j'ai compris !!!
(pas l'explication du problème mais la différence entre mon cas réel et l'exemple)

-> c'est en effet une histoire de taille de fichier.

Voila :

Si la taille de $1 est < 32768, ca marche.

Le problème est donc le suivant :
(.|\n)* match sans problème tout dans la version 5.8.8.
Mais dans la version 5.10.0, il ne pourra matcher que moins de 32Ko de données, après, ca ne matche plus !

Résultat: si on met 31.9Ko de données avant, ca renverra le premier PROUT (1246337630) puisqu'il ne peut pas inclure les 2 lignes PROUT dans (.|\n)* qui feraient alors plus de 32Ko.

C'est un peu comme si le * appliqué à une parenthèse commencait à chercher à 32Ko (ou 32K répétitions) et non au maximum de la chaine.
* appliqué à [\S\s] est en revanche illimité !

C'est incroyable, pourtant, c'était illimité dans le 5.8.8 !

Quelqu'un aurait une explication ?
et encore une fois: que faut-il utiliser ? [\S\s] ?

Tu as essayé ceci pour matcher le contenu de ton fichier:

{                        # le slurp mode, vaut mieux pas le mettre en global
  local $/;             # on se met en "slurp" mode
  local $_ = <FH>;  # tu remplaces par un file handle sur ton fichier
  if (/^((.|\n)*)\S+\s(\d{10})\s+\S+\s+\S+\s+PROUT\s/i ) {
      print("presize = ".length($1)."\n" );
      print("$3\n" );
   }
}

le slurp mode devrait coller, i.e. faire qu'on n'est pas limité en taille de l'input, sinon, c'est peut être un bug de cette version de Perl
 
Sinon, perso, je préfère (\n|.) ou plutôt (.|\n) a [\S\s] mais je pense que c'est du pareil au même en terme de performances.
 
A+,

Salut !
 
ok, en effet, mais le problème c'est que tu es obligé d'utiliser un fichier et non une variable.
or dans mon cas personnel c'est une variable, j'ai juste simplifié avec un fichier pour l'exemple !
 
Pour les performances je viens de faire le test !
 
Voila :

 
Les résultats vont du simple au triple !
=> j'ai mis le temps que prend une boucle for à coté de chaque if.
(j'ai testé 3 fois pour chaque cas pour etre sur car c'était sur un pc déja assez occupé à faire autre chose)
 
CONCLUSIONS:
 
Donc le plus rapide est clairement [\S\s]
J'ai fait un cas 2 car je me doutais que le fait de mettre une parenthèse ralentirait un peu...
 
[\S\s] est 2 fois plus rapide que (.|\n)
[\S\s] est 3 fois plus rapide que (\n|.)
 
(.|\n) est plus rapide que (\n|.) sans doute parce qu'il y a plus souvent des . que des \n, or (\n|.) commence à chaque fois par chercher des \n.
 
PS: [\s\S] semble strictement aussi rapide que [\S\s]

Ce n'est pas le comportement que je vois: Il passe dans le test, même si on depasse 32ko
Il matche (j'ai testé avec une variable et un fichier, tous deux de taille 76ko), mais il discarde de $1 a partir du 32700e caractere (inclus)
La taille max de ce qui est stocké dans $1 est 32699 apparement et quand il atteint cette taille max, le matching complet avec l'assignation de $3 est effectuée  (ce qu'on a dans $3 n'est pas la dernière valeur du fichier si celui ci fait plus de 32ko.)
 
C'est un bug de cette version de perl, signalé dans la base des bugs de perl
 
A+,

oui bien sur ca revient à ce que je disais :
 
lorsqu'on utilise * (et non *? ) ca commence à matcher au maximum.
et donc (.|\n)* devrait commencer à faire le maximum possible, c'est à dire tout le fichier (toute la variable)
or dans 5.10.0, ca commence à matcher à 32Ko de données et non après.
 
Lorsque je disais "ca ne matche pas" c'est parce que mon PROUT était plus loin que 32768 caractères.
 
Sinon je crois que la réponse à mon topic est donc définitivement [\S\s] car bien plus rapide ! (et au moins ca marche dans tous les cas)

Ça arrête de matcher a 32Ko de données, en fait.
A+,  

non, ca arrêterait de matcher à 32K si on faisait comme ceci :
/^((.|\n)*?)PROUT/
 
or en l'absence de "?", ca commence à matcher au maximum, donc en l'occurrence 32K :
/^((.|\n)*)PROUT/
 
Dans le premier cas, ca essayera de matcher de 0 à 32K de données alors que dans le second c'est l'inverse: de 32K à 0.

j'ai testé avec des tailles de fichier variables
Ca matche jusqu'à 32k, et ca n'essaye pas de matcher au dela (ie la valeur que tu as en $3 est celle associée a la taille maximale de $1, ie 32k). Tout se passe comme si, lorsque $1 avait atteint la taille maximale admissible pour lui (32k ici), il arrêtait de matcher.
A+,

Salut,
 
ok, donc je crois que tu n'as pas compris comment fonctionne "*"
 
* répèete au maximum ce qui précède (caractère unique, parenthèse entière ou jeu de caractères [...])
 
MAIS,
* seul commence  à matcher au MAXIMUM possible.
 
Par ex:

-> ici, c'est "2" qui s'affichera, et non "1".
Ceci parce que .* signifie "autant de caractères que possible (sauf \n)
.* COMMENCE donc à matcher au maximum possible: toute la chaine.
 
Maintenant :

-> ici, c'est "1" qui s'affichera, et non "2".
Parce que *? signifie "tout sauf \n autant de fois que possible", MAIS "en commencant par le plus petit possible".
 
Donc,
lorsqu'on utilise (.|\n)* et qu'on s'apercoit qu'il ne peut pas matcher plus de 32Ko de données, c'est non pas parce qu'il s'arrête de matcher en arrivant à 32Ko, mais parce qu'il COMMENCE à 32K avant de descendre à 0.
(.|\n)*? en revanche, commence à 0 et s'arrête à 32Ko.
 
Voila, juste une petite nuance sur le fonctionnement des regexp
@++

La tu fais des suppositions sur la manière dont le moteur d'expression régulière fonctionne.
Sans doc d'implémentation, je n'ai aucune raison de croire que ça fonctionne de cette manière (ie de la droite vers la gauche, par réduction, et non de la gauche vers la droite, par augmentation, surtout que cette dernière méthode est celle habituellement utilisée par les automates d'états finis associés aux expressions régulières).
A+,

comment peut-on imaginer que lorsqu'on fait (.|\n)* ca commencerait à chercher au plus petit, pour laisser passer des "solutions" qui matchent, puis une fois arrivé à la fin, revenir en arrière en disant "ah oui, il y avait ca qui matche donc c'est ca le plus grand...

Ce serait terriblement mal concu !

Il est évident que lorsqu'on utilise *, ca commence directement a chercher  au plus grand, et tu t'en apercevrais forcément en faisant des tests de rapidité :

/^(.|\n)*PROUT/

Test 1:
variable de 31K de données puis PROUT après.

Test 2:
variable de 31K de données mais avec PROUT qu'au tout début.

En utilisant ma boucle de chrono, tu verrais que le test 1 est plus rapide.

Inversement, si on utilisait (.|\n)*? c'est le 2 qui serait plus rapide.

Tout simplement parce que c'est comme ça que ça marche si vous remplacez votre * par un {n} (ou n est en entier positif). Et parce que si on connait un peu la théorie sous-jacente au pattern matching, c'est a dire les automates d'état fini, on sait que c'est ainsi que c'est en général implémenté.
Et non, on ne revient pas en arrière une fois arrivé a la fin: chaque fois qu'on trouve une nouvelle solution, elle remplace la solution courante, s'il y en a une. Ainsi, quand on arrive a la fin, on prend la solution courante (si elle existe).
Mais bon, comme j'ai dit, je ne sais pas si dans le cas d'une *, c'est l'algo pour {n} qui est appliqué, ou si il y a une optimisation particulière, faisant commencer par la fin. Je n'ai pas eu l'occasion de lire le source C du moteur d'expression régulière de Perl.
A+,