Newsgroup: it.comp.www.php
Titolo: Regexp che fa cose strane

Abbiamo 3 server: 1 vecchio Mandriva 2007, 1 RedHat Enterprise 5, 1 
CentOs 5.3
La seguente regexp produce il risultato corretto (cancellazione 
dell'ultimo spazio bianco) su Mandriva:
<?php
$string=<<<EREDOC
<strong>1</strong> - Caricamento<br />
<strong>2</strong> - Controllo<br />
<strong>3</strong> - Taglio<br />
<strong>4</strong> - Alimentazione<br />
<strong>5</strong> - Scarico
EREDOC;
$string = ereg_replace("\s+"," ",$string);
echo $string;
?>
La stessa funzione su RedHat e CentOS produce il seguente risultato:
< trong>1</ trong> - Caricamento<br />
< trong>2</ trong> - Controllo<br />
< trong>3</ trong> - Taglio<br />
< trong>4</ trong> - Alimentazione<br />
< trong>5</ trong> - Scarico
con l'aggiunta di un 'BAD_RGXP' nel log.
Capita anche a qualcun altro?
Andrea
PS: abbiamo giï¿œ sostituito tutte le ereg con preg
PS1: \s+ ï¿œ solo l'esempio piï¿œ semplice, ne sbaglia anche altre.

Quasimodo ha scritto:

Prova a raddoppiare il backslash, o a mettere le stringhe tra apici singoli
( ' ' )
Ogni tanto funziona: non sai perche', ma funziona... mi e' capitato un paio di
volte.
Astro

$string = ereg_replace("\s+"," ",$string);
Credo che debba essere
$string = ereg_replace("\\s+"," ",$string);
altrimenti ti sostituisce le "s" e non i whitespace.
Poi magari qualche libreria piu' rilassata, o un PHP piu' tollerante, "sa"
che l'escape di stringa \s non esiste e lo lascia come \s anziche' fare il
collasso a s; ma IMHO e' bene non farci conto.
Leonardo
-- 
Linten addie toorin addie,
Linten addie toorin ee,
Linten lowrin lowrin lowrin,
The barnyards of Delgaty

 Leonardo
Questa del doppio backslash mi mancava. Quale libreria fa riferimento 
(egrep?)? Eppure sono espressioni POSIX, dovrebbero essere facilmente 
validabili...
 

validabili...
Non e' colpa della regexp. In PHP, "\n" e' un carattere solo, un ritorno
carrello. "\q" cos'e'? Quando il parser vede \, entra in escape mode, ma
cosa fa quando vede una "q" e non una r, n, b, t, $, \, eccetera?
Secondo alcune interpretazioni, dovrebbe uscire dall'escape mode facendo
una recovery (e quindi "\q" => '\' + 'q'), ma secondo altre, e non tutte
intenzionali <grin>, dovrebbe effettuare un collapse (cioe' \[x] diventa
sempre un solo carattere, quale che sia [x]: e "\q" => 'q').
In questo secondo caso pero' se tu dici al PHP "\s" (quattro caratteri),
volendo passare allo strato sotto, i due caratteri \s, il PHP interpreta
nel proprio bytecode s (un carattere solo), e la regexp dice "Ah! Una s!
Non c'e' problema" -- e ti castra tutte le esse.
http://www.skdevelopment.com/php-regular-expressions.php
Puoi verificare cosa succede eseguendo questo:
<?php	die("Sono " . strlen("\x") . " caratteri.\n");  ?>
Io ho sempre avuto risposta "2" - ma mi ricordo di aver beccato 1 su una
Fedora un annetto fa. Controllato ora, su SuSE e (credo) Ubuntu: 2, come
ti saresti aspettato anche tu.


Leonardo Serni ha scritto:

Allora, fatti alcuni test:
-CentOS/RedHat/Mandriva mi rispondono tutti "2 caratteri".
-CentOS/RedHat rispondono cos�:
   -> "\s+"	-> cancellazione di tutte le 's'
   -> "\\s+"	-> cancellazione di tutte le 's'
   -> "\[s]+"	-> nessuna azione apparente
   -> "\\[s]+"	-> nessuna azione apparente
-Mandriva risponde cos�:
   -> "\s+"	-> cancellazione dei trailing spaces e del \n finale
   -> "\\s+"	-> cancellazione dei trailing spaces e del \n finale
   -> "\[s]+"	-> nessuna azione apparente
   -> "\\[s]+"	-> nessuna azione apparente
Mah...
Andrea

 Andrea
Passare ai singoli apici? Di solito ti risolve i problemi... prova...
Astro

   -> "\[s]+"	-> nessuna azione apparente
Quest'ultima cosa e' piuttosto strana. Mi sarei aspettato che non
cambiasse nulla rispetto al caso precedente. E' comunque di certo
un problema di escaping, a meno che...
...c'e' differenza fra "[s]+" e "[s][s]*" ?
Leonardo che ha visto pure questo


Astro ha scritto:

Non � servito...

 
Nessuna differenza...
Non esistono dei pattern 'ufficiali' su cui collaudare le regex?