inconsistent warning production

[JimJJewett]

I'm trying to migrate an existing website from Apache to a
Sun Java Systems (Sun One) server. The Perl interpreter
seems to behave differently in otherwise similar environments;
I can't figure out why.

In particular, some sloppy code doesn't trigger so much as a
warning on the old machine, but sends these warnings to the
output HTML page on the new machine. (The script then continues
and produces the same correct output page from then on.)

Running with/without -w doesn't seem to affect this on either
machine. (It does affect other things.) I couldn't find any
environment variable settings (either in the web user's shell
or from an env.pl cgi script) that would seem likely to affect
what happens to warnings.

Both are Sun Solaris machines (the new one is 2.8 instead of 2.4)
The old perl is 5.004 and the new is 5.005003

In both environments, the following code successfully reads an
input file to create option lists; my only question is why the
error verbosity changed.

-- input format --
[group1]

val1
val2

[group2]

val3

-- code --

sub get_list
{
my ($k);

$T = new FileHandle;
$T->open("< $tables_file");
while(<$T>)
{
chomp;

if(/^\[(.+)\]$/) { $k = $1; eval "undef \%".$_;}

# jjj - this works cleanly
# jjj added the parentheses around the undef argument
# jjj changed undef target from $_ to $k
#if (/^\[(.+)\]$/) { $k = $1; eval "undef (\%".$k.")"; }
else { eval "\$".$k."{\'".$_."\'} = 1"; }
}
$T->close;
}

-- output --
On the new box, every [group] line spits out a pair of warnings, such
as:

Warning: Use of "undef" without parens is ambiguous at (eval 8) line 1,
chunk 1.Bareword found where operator expected at (eval 8) line 1, near
"%[color" (Missing operator before color?)

-jJ

 

[Brian McCauley]

I'm trying to migrate an existing website from Apache to a
Sun Java Systems (Sun One) server. The Perl interpreter
seems to behave differently in otherwise similar environments;
I can't figure out why.

In particular, some sloppy code doesn't trigger so much as a
warning on the old machine, but sends these warnings to the
output HTML page on the new machine.

If STDERR is showing up in your web pages and not in the web server
error log then there is something wrong with your webserver. (This, of
course, has nothing to do with Perl).

(The script then continues
and produces the same correct output page from then on.)

I'd suggest fixing the code.

Running with/without -w doesn't seem to affect this on either
machine. (It does affect other things.) I couldn't find any
environment variable settings (either in the web user's shell
or from an env.pl cgi script) that would seem likely to affect
what happens to warnings.

In later versions of Perl when eval(STRING) gets an error during the
compliation of STRING the value retuned in $@ may just be the basic
error. Any additional supporting information is treated as manatory
warnings and emitted to STDERR.

Both are Sun Solaris machines (the new one is 2.8 instead of 2.4)
The old perl is 5.004 and the new is 5.005003

That's not old and new. That very very old and very old.

if(/^\[(.+)\]$/) { $k = $1; eval "undef \%".$_;}

# jjj - this works cleanly
# jjj added the parentheses around the undef argument
# jjj changed undef target from $_ to $k
#if (/^\[(.+)\]$/) { $k = $1; eval "undef (\%".$k.")"; }
else { eval "\$".$k."{\'".$_."\'} = 1"; }
}
$T->close;
}

Since you claim the broken code was "working" on 5.4 (where it was
failing silently rather than emitting errors to STDERR) why not simply
remove the broken code rather than (half) fix it?

Note: Using symrefs (or worse using eval() to simulate symrefs) like
this is bad.