inconsistent warning production

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

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 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 --




-- code --

sub get_list
  my ($k);

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

    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"; }

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

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?)


Re: inconsistent warning production wrote:
Quoted text here. Click to load it

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).

Quoted text here. Click to load it

I'd suggest fixing the code.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.

Site Timeline