in reply to newkid confused: reverse then unreverse a string

Well, let's see what you're actually doing:
$comment = "My lawyer is named will"; for ($new = $comment) { $comment = &doit($comment); }
Okay, this is probably not what you intend. This takes $new, and sets it equal to $comment. Then this is treated as a list (of 1 item), which is assigned to $_ in the for loop (the s// will by default work on $_), and then $comment is set equal to the result of doit().
sub doit{ $go = ";gie/moT/lliw/s ;gie/reknaB/reywal/s ;gie/yenraB/derf/s";
This sets $go equal to that string.
$com = join("", reverse split(//, $go));
This sets $com equal to the result of this.
return $com; } print $new;
which is then returned ($new being set equal to that).

It seems you want to _run_ those searches against $new. You'll want an eval() statement to do that. (Why is left to your own twisted goals). I suggest you study the for() loop because I suspect you are misunderstanding what it is doing.

Update: eval() can be a security risk if you are running anything that can be affected by user input, particularly on a web page. I suggest you use perl's taint mode, and CGI.pm

Replies are listed 'Best First'.
Re:(2) newkid confused
by swiftone (Curate) on Apr 05, 2002 at 22:07 UTC
    Here's a cleaned up version with some explanatory text. hope it helps, I have no idea why you would want to do this.

    #!/usr/bin/perl -wT #warnings and Taint checking on, see perlsec #CGI scripts should almost always use CGI.pm use CGI; use strict; #strict is your friend my $q = new CGI; print $q->header(); #print the header my $comment = "My lawyer is named will"; #this loops over the list in the parens, aliasing $new to each in turn #pointless, but presumably you anticipate having more than one in the +list for my $new ($comment) { $new = doit($new); #We act on $new, which will affect whichever lis +t element we're on } print $comment; #$comment, not $new. $new was only inside the loop sub doit{ my ($passed_string) = @_; #get the list we're passed, drop all but + first item #Note that I removed the "e" flags below, you aren't interpreting an +ything my $go = ";gi/moT/lliw/s ;gi/reknaB/reywal/s ;gi/yenraB/derf/s"; my $com = scalar reverse $go; $_ = $passed_string; #so that s// will work on it. eval $com or die $!; return $_; }
    Update: Cleaned it up a bit, thanks to BazB and podmaster for the assist
      Thanks ! The Reason: The string is actually lots longer. I have collected a Looonnnggg list of cusswords, in several languages, and the substitutions are for moronic language entered in a comments form. I would rather not show all the words to delicate people, if I ever run across any that is, so I like the s/'s backwards in the script. For example:
      s/bit*h/barbie/ or s/wh*re/exwife/ etc.
      I will study eval and the security problems.
        It would be nice to have a standard-issue CPAN module for checking so-called "cusswords", perhaps in the Lingua branch, as in, Lingua::Foul or what have you.

        Just like rolling your own HTML parser or CGI handler is such a waste of time, this sort of thing is done all the time, and probably done badly too. Though "badly" is not necessarily because of bad programming, but because of not having thought it all the way through.

        What I mean specifically is that a group of people, from different backgrounds, will certainly come up with a better module than a single person.

        There are many words which are not foul, but are constantly picked up by filters which are too paranoid. As an example, consider "shittake mushrooms" or even "gratitude", which I have seen banned because it contains "tit". Heck, there are hockey players named Satan ("Sha-tan" presumably) and a town in Austria named Fucking ("Foo-king").

        The chile system used in Eudora is interesting, because it does not block messages, but warns about the content of them based on triggers. A good module would have to do the same, perhaps giving an indication of the "spicy" nature of the text.

        A robust detection system could then be extended to star-out, omit, replace, or otherwise handle any foul language, but ultimately at the discretion of the programmer and perhaps any user settings.

        I'm sure there are a lot of people who would likely want to use a module like this, but have no intention of writing one.