while ($content =~ m!($code_regex)!go) {
      my $match = $1;
      $content =~ s!$match!$match$href1$i$href2!;
      $i++;
  }
[download]

You can't use m//g in a scalar context when you are modifying the string you are matching against between scalar m//g's. I bet the $content =~ s!!! is resetting pos($content) to 0 each time, causing the infinite loop. The random order of matching is probably the debugger trying but not succeeding to restore complex regex context. In this case, debug with print statements. ):

$basename = 'http://www.perlmonks.org/';
$content =~ s!href="$basename!...
[download]

Sheesh. That's what I get for posting code too quickly. Fortunately, this hasn't caused a problem as I have used exclamation points as delimiters (and avoided the problem with the slashes) and the dot metacharacters match the actual dot characters. I got lucky! Thanks for pointing that out.

This has actually caused me a problem with the $match variable as this will often contain characters that will have special meaning in a regex, but I can't simply wrap them in \Q and \E because of the problems with $ and @, so I'm going to write a short snippet that will handle that substitution for me, but this is turning out to be just a more difficult problem than I imagined!

Cheers,
Ovid

If you want to have the variable contents being interpreted as a string literal rather than regex chars, the perlfunc:quotemeta function is useful.

I tried something like s///ge at one point, but it doesn't work in this case. The /e causes the right hand side of s/// to be handled as code to eval. Well, since we are deliberately matching Perl code with this regex, this solution tends to choke quite spectacularly.

I think its probably cause your substituting stuff into content, making the string different when it tries to do a second match...

Oh!!!!! Good point. Didn't think Perl would bomb on that. Need to go check it out. Thanks.

Cheers,
Ovid

Update: Oops. Just noticed that tye pointed out the same problem and I've verified that it's the bug. Here's a bit of sample code that can reproduce it (don't do this at home, kids):

#!/usr/bin/perl 

$string = "1";

# Infinite loop caused by modifying the string we are matching against
+ in while statement

while ($string =~ /(\d)/g) {
    $match = $1;
    $string =~ s/$match/$match/;
}
print $string;
[download]

Update 2: After reading through Boogman and tilly's comments below, I'll have to see what I can do to reproduce the /e error. It was rather frustrating.

The /e causes the right hand side of s/// to be handled as code to eval. Well, since we are deliberately matching Perl code with this regex, this solution tends to choke quite spectacularly.

Hmmm... Thats strange. I decided to fool around with it and tried this out:

my $i = 1;
my $string = 'print "hello";';
my $content = 'print "hello";$x + 2; print "hello";print "hello";print
+ "hello";';

$content =~ s/($string)/$1.$i++."\n"/ge;

print "$content\n";

eval $string;
[download]

and it printed out

print "hello";1
$x + 2; print "hello";2
print "hello";3
print "hello";4

hello
[download]

It doesn't seem that it executed the print statement that was matched, even though if we hand the string directly to exec, it does print out hello.

Everything allows you to create different "htmlpages" for types, so we created a "document downloadcode page", with no nested containers around it:

[%


  
  my $text = $$NODE{doctext};

  my $str;
  while($text=~/<CODE>((.|\n)*?)<\/CODE>/ig) {
    my $code = $1;
    $str.=$code."\n\n\n";
  }
  $str;


%]
[download]

All that was left was to hack in a change of content type to "application/octet" in the core, and viola!

Uh, what the heck is application/octet? Why not send it as it really is, text/plain, and that way it gets the right download type on every machine, and let me decide whether I want to see it in my browser, or dictate to my browser that I want to save it on disk?

Yours for a better web,

-- Randal L. Schwartz, Perl hacker

yeah that should have been application/octet-stream but text/plain works too

vroom | Tim Vroom | vroom@cs.hope.edu

Cool, now I can view it in my browser and cut/paste there, or hit option-click and it downloads as a nice Mac-OK text file! Thanks!

-- Randal L. Schwartz, Perl hacker