If we look at the very first code snippet of the newest Perl Cookbook article at perl.com, we'll notice a clever trick, using a regular expression object recursively inside a (??{CODE}) construct. (This regular expression trick is also used in the SelfLoader and AutoSplit modules, that come with perl.) However, the regular expression object is stored in a lexical variable, and this involves additional (and unusual) trickery in the regular expression compiler, not unrelated to the fact that the (??{CODE}) block is treated like a closure. That part of perl is not well tested and does not behave always properly. Dave Mitchell added recently a new warning case, producing the message Variable $np is not available, that indicates that the lexical context for $np couldn't be captured while compiling a closure that refers to it. It appears that, under some conditions that I don't understand fully, that code snippet produces this warning. The workaround is obviously that $np shouldn't be a lexical variable, but a global one : declare it with our. (See also patch #20578 to perl about this.)