on 2/8/99 10:31 AM, Chris Nandor wrote... >At 09.18 -0500 1999.02.08, Scott Prince wrote: >>I thought that the sequence below would clean up any nasties from form >>data submitted through my cgi's. >> >>$form_data{$user_entry} =~ s/<(.|\n)*>//g; # html > >Three things. Note that the /s modifier makes . include newlines. Also >note that your regex will be greedy; it will swallow up everything between >two sets of HTML tags. You probably want ?. > > s/<.*?>//gs Noted, thanks. Greedy was the idea, but you make a good point that I have overlooked in other cases. >But I don't know what you are saying the problem is. You're saying that >\n's or \r's are in the text? They shouldn't be. Whatever your newline >characters are, for Mac, Unix, or Windows, s/\r|\n/ /g or s/[\r\n]/ /g >would remove them all. No they weren't there, but there was a character that was translated by Fetch as a \n that was not a \n. A bug in Fetch, the result of the way the character was interpreted by a platform, due to a bug in my script? I really don't know and haven't been able to reproduce it. It wasn't a problem, just an annoyance. Viewing the file with Fetch clearly showed the database records broken mid-field with a \n, but the script(on unix - admittedly slightly off topic) churned out the records properly nonetheless. This would of course be impossible if there were actually a \n in a database field. >>The book, "Perl5 by Example" has a table listing all the usual escape >>char's, but, further into the book there is a code example using the >>escape /cM. A quick test verifies that MacPerl recognizes this as a /r. > >No. MacPerl sees \cM as \n, and \cJ as \r. Unix and Windows do the >opposite. \cM, \cJ? I have rarely seen these. Just out curiosity, where could I find a list of every possible escape sequence recognized by Perl? Scott Prince ***** Want to unsubscribe from this list? ***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch