[smokeping-users] Can't find lib.pm in @INC

[G.W. Haywood]

Hi Eric,

On Mon, 24 Nov 2008, Eric Chatham wrote:

> When I made the change, to #!/usr/bin/perl -w in smokeping.cgi, I received the following warnings from perl when I executed it (./smokeping.cgi):
>
> [Mon Nov 24 16:46:26 2008] smokeping.cgi [client (unknown)]: Use of uninitialized value in substitution (s///) at (eval 34) line 44.
> [Mon Nov 24 16:46:26 2008] smokeping.cgi [client (unknown)]: Use of uninitialized value in concatenation (.) or string at (eval 43) line 15.

You mean that you executed smokeping.cgi from the command line?
That's always going to give you errors, smokeping.cgi is intended to
be executed by Apache (in response to a client request) which happens
when you type this into your browser:

http://server.domain/cgi-bin/smokeping.cgi

Apache will feed a lot of data to smokeping.cgi, the data will be used
to initialize those uninitialized values and smokeping.cgi will return
something to Apache, which Apache will send, probably verbatim, to the
client.

> ...
>     14  Smokeping::cgi("/opt/smokeping/etc/config");
>     15
>     16  =head1 NAME
> ...

Hmmm.  A blank line at line 15.  I probably should mention that you
can't always rely on the line numbers Perl gives you, sometimes weird
things throw off Perl's line counting - and sometimes Perl's line
counting is just weird.  Anyway if you're running the cgi script from
the command line it really doesn't matter where your errors come from.

It looks like the script itself is working as it's supposed to.  All
it does it send a lot of dynamically generated HTML to stdout - which
will normally be the terminal, if you run it from the terminal - but
which will be mopped up by Apache if Apache ran it as it's supposed to.

> Do you think it may have to do with the SpeedyCGI installation?

Probably only if you use it. :)  I doubt that SpeedyCGI will romp
around your system modifying @INC if you don't call it in scripts.

Just to recap: your script was complaining that it couldn't find
things, and apparently it was looking in the wrong places - places
that at the moment I think it should only have been looking if there's
an installation of Perl 5.005_03 on your system, and it's starting to
look like there might not be.  So I'd like to know what made it want
to look there because I think that's a problem that needs fixing.  It
may not be the only problem of course, but we'll have to take things
one step at a time.

> [root at hppav htdocs]# locate perl | grep bin
> ...
> /usr/bin/perl
> /usr/bin/perl5.8.8

I'm guessing (again) that /usr/bin/perl is just a symlink to
/usr/bin/perl5.8.8, yes?  If so we still don't have a culprit.

> > If 5.8.8 is the only Perl on the system then I'd still want to know
> > why there were all those useless paths in that error message.
>
> I'm not sure where else to check.  Could it be SpeedyCGI? :)

Hehe, not if you don't enable it. :)  I kind of tried to talk you
out of it as I think at this stage it just adds one more variable
and there are too many already, but I don't want to discourage you
from experimenting.  I usually learn a lot when I do that.

It's late here in the UK.  Post a status report when you have more.
I'm starting to think it might be time to take a step back, or two.
Back to the basics.

--

73,
Ged.