Trapping chr(10)

[audiopro]

$INTEST =~ s/[^a-zA-Z0-9@\/.,: <>&()-]//g;
$INTEST=~ s/\n//g;
$INTEST=~ s/\r//g;

This is allowing chr(10) through, what am I missing?

Keith

http://www.studiosoft.co.uk

 

[PaulTEG]

Not sure, clutchalert=True;

Try putting the first line at the end ...

\n==>chr(10)
\r==>chr(13)

looks fine to me

Paul
------------------------------------
Spend an hour a week on CPAN, helps cure all known programming ailments ;-)

 

[ishnid]

Aren't the second and third replacements superfluous, as those characters should be removed by the first regexp anyway?

Either way, a transliteration is probably more efficient, since you're only replacing single characters:

 $string =~ tr/a-zA-Z0-9@\/.,: <>&()-//cd;

 

[PaulTEG]

Can you give us a sample of the bogey string?

Paul
------------------------------------
Spend an hour a week on CPAN, helps cure all known programming ailments ;-)

 

[NullTerminator]

Don't we need the /m switch to process multilines?

Other wise we are processing aline at a time and don't see the \r or \n

Jeb

 

[audiopro]

Do I need the /m switch to process multi lines?

Sorry chaps, it was me being a dummy.
I had an old record in my table with a line feed in it and that was the cause of the erratic behaviour.
Thanks anyway.

Keith

http://www.studiosoft.co.uk

 

[PaulTEG]

/m would be only if you're reading from a file I would have thought.

I've had no problems replacing "\n"'s in a string, coulda been just lucky I guess

--Paul

Paul
------------------------------------
Spend an hour a week on CPAN, helps cure all known programming ailments ;-)

 

[audiopro]

I have a couple of incoming text areas to check but I suppose removing all line feeds will leave a single string anyway.

Keith

http://www.studiosoft.co.uk