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. > [EMAIL PROTECTED] 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. _______________________________________________ smokeping-users mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users
