However, remember that $a and $b are package variables, so if you're executing this code in a different package than where $a and $b got the values you want them to have, it probably won't work.

On the other hand, you might try using explicitly declared lexical variables, like $x and $y, and see if that makes a difference.

Can you post more code?

$a and $b can be declared lexically and then will have whatever value is assigned to them, if any. They don't have to be package variables (though they are if they haven't been assigned to). Still, I agree that it's a good idea not to use these variables. Of course, $x and $y might not be very descriptive, depending upon how they are used :)

Cheers,
Ovid

Join the Perlmonks Setiathome Group.
New address of my CGI Course.

Been there. Paid the price. No t-shirt.

Let me suggest the advice to newbies be stronger than "it's a good idea not to".

Yes, $a and $b can be declared lexically and they work fine. But this trashes their subsequent use in a sort within the same scope.

I wasted half a day recently trying to debug a failing sort. After much gnashing of teeth I finally discovered that $a and $b had been declared and used at an earlier stage in the routine. I changed $a and $b to meaningful names and the later sort ran fine.

My advice: Just say no to "my ($a, $b);" It will work fine in the immediate context but some time in the future you or someone else may decide to sort something at a later point in the same scope -- and there will be much needless weeping and wailing until you discover the problem.

In addition to the answer you already have, try to avoid using $a and $b anwhere outside of a sort function where, of course, they have special meaning.

ps 'Try to avoid' is a nice, Canadian way of saying never, ever do this .. just so you get my meaning. :)

$a = 2;
$b = "-";
$base = "ABCABC";

$stemp = "\/" . "ABC" x $a . "\/";
$regxp = eval 'qr' . $stemp;
$base =~ s/$regxp/$b/g;
[download]

$base =~ s/[ABC]{$multi}/$replace/g;
[download]