in reply to Re: Useuninitialized value in string eq at line 44, <READER> line 1 (#1)
in thread Use uninitialized value in string eq at line 44, <READER> line 1 (#1)

Thanks, that did the trick. What is the bang! for before define do.
if (!defined $events1 or $events1 eq "")...

Now I am getting this error.
Use of uninitialized value in concatenation (.) or string at post_events.cgi line 60 (#1)
Line 60 staarts at the print statement
print WRITER"<table border='0' width='100%'> <tr> <td width='17%' valign='top' align='right'><font SIZE='+1' colo +r='gray'><B>$events[0] $events[1], $events[2]</B></font></td> <td width='83%' valign='top'><font SIZE='+1'color='black'><B>$even +ts[3]</B>&nbsp;&nbsp;&nbsp; $lc</font></td> </tr> <tr> <td width='17%' valign='top' align='right'></td> <td width='83%'><font SIZE='2'>$events[4]</font></td> </tr> </table>"

Cal
  • Comment on Re: Re: Useuninitialized value in string eq at line 44, <READER> line 1 (#1)
  • Download Code

Replies are listed 'Best First'.
Re: Re: Re: Useuninitialized value in string eq at line 44, <READER> line 1 (#1)
by BrowserUk (Patriarch) on Jul 21, 2002 at 21:05 UTC

    Thanks, that did the trick. What is the bang! for before define do. if (!defined $events1 or $events1 eq "")...
    The bang! is logical negation (see perlman:perlop), so if !defined ... reads "if not defined...".

    In your split statement, if there is nothing after the "::" on that line, then there will be nothing to put into $event[1], therefore $event[1] will not be created, and is undefined or !defined().

    Testing for this first probably renders the or $event[1} eq "" redundant, but it is difficult to know for sure without sight of the data.

    BTW: it is (slightly) better to do ...eq '' rather than ...eq "" I think as, unless the Perl compile stage optomises this, the ""; it could mean that the "" invokes a check for interpolation.

    (Somebody will correct me if this is a mistaken assumption:)

    Use of uninitialized value in concatenation (.) or string at post_events.cgi line 60 (#1) Line 60 staarts at the print statement

    This almost certainly means that one (or more) of the elements of your @events[0..3] array received no value from the split.

    Update: I was wrong! The @events = ''; does nothing useful as a new array is created by the split.

    The best solution I have come up with (quickly) is to test the size of the array after the split using scalar @events and then take some action to correct the situation of you did not get as much data as you wanted. If not having enough data to display is okay given the logic of you code, you could do one of two things.

    Wrap the code where you know this may occur and is acceptable in an anonymous block (ie. {}) and set no warnings at the top of that block:

    ... { no warnings; # Known warnings are ok here. print ....$event[0]...$event[1]...$event[2]....event[3]; }

    Or, and better in my opinion, though there is almost certainly a better (more idiomatic) way of coding this. Check the number of elements after the split and then 'top up' the array with 'okay' values before the code that uses them.

    Something like:

    @events = split....; push @events, ('&nbsp;') x (4 - scalar @events ) if (scalar @events < +4) ; print...;

    I have spent much time banging my head on this one, I am not surprised so many Perl beginners are tempted to run their code without warnings, when simply switching them off seems to allow their programs to run ok.

    Of course, it is short-sighted in the long term.

    I also haven't happened across any good discussion on the subject of uninitialised values yet. Maybe its not something that can easily be documented in a "if you get this, then look for that and/or do the other" type of way, and you simply have to learn by your mistakes.