mod_perl下'\\'的奇怪行为

Question

I have the following in a script that runs under mod_perl

Logger::log("\$1 = '$1'");
Logger::log("\$ 1 = '$1'");
Logger::log("\\$1 = '$1'");

Which outputs the following into my log file:

logger:  = ''
logger: $ 1 = ''
logger: \ = ''

$1 is known to be null. Is this a bug in mod_perl2 or is it something else I'm missing?

Answer 1

Did you try:

Logger::log(q!$1 = '! . $1 . q!'!);

or, to avoid warnings:

Logger::log(q!$1 = '! . ( defined $1 ? $1 : '' ) . q!'!);

The idea here is that q!...! doesn't interpolate its contents, so you know for sure the first part of the string will be $1 = ". If it's still not appearing in the output, then you know Logger::log() or something it calls is interpolating its arguments, which probably shouldn't happen.

Oh, and if you're using a more modern Perl, the second example can use ( $1 // '' ) instead.

Answer 2

If you're worried about catching and accidently printing nulls, there's a quick and easy way that almost everyone will recommend you do first: add the following to your program:

use strict;
use warnings;

The problem in particular seems odd; when I do

my $foo = 'zip';
$foo =~ /(bal)/;
print "\$1: '$1'";

I get

$1: ''

(and with use strict and warnings, the additional error

Use of uninitialized value in concatenation (.) or string at - line 5.

Of course, you can prevent $1 from ever being null if you test your regex:

if ($foo =~ /(pattern)/) {
    # $1 is guaranteed to be ok here, if it matched
}

So yeah, it might be your logger re-interpreting $1 as something else. Try adding two more \\\\ ; one for escaping the $, and another for escaping an extra backslash. Thus it'd look like

print "\\\$1: '$1'";