Right, FlieZilla was pushing files onto the server using an auto setting. I’ve just forced it to push it as ASCII, but got the same failed result.
I’ve also checked the encoding on ST3 and that’s set to the default ‘UTF-8’ - not something I’ve ever tinkered with.
It’s beginning to look like there’s something about the creation & transfer of the file from an external client that the server Perl program doesn’t like. Something it doesn’t get when nano is used to create a file.
I’ve been wondering about the ASCII - binary, BOM myself.
I created a very simple new file in nano and chmod it
#!/usr/bin/perl
print "Content-type: text/html\n\n":
perlinfo();
I kept getting server errors. The log showed “output header” errors
So I tried changing to
#!/usr/bin/perl -w
use strict;
use HTML::Perlinfo;
use CGI qw(header);
print header;
perlinfo();
Same FAIL.
I was really scratching my head trying to figure out what was different that was causing the error.
I ended up needing to run
sudo cpan install HTML::Perlinfo::Modules
Now it works great.
Granted, I’m not the best terrible at reading error logs, but I didn’t see any type of “missing” message. This led me to believe the file had a syntax error causing the server error.
The only way I figured it out was by repeatedly Googling, trial and error, and eventually luck.
I think my next search will be to try and find a better way to deal with debugging.
@Mittineague You didn’t get a 'undefined subroutine "perlinfo"' at your first try? Or a 'can't locate HTML::Perlinfo in @INC' on the second try?
Checking for BOM you could do by running the file through hexdump and look for 0xEF 0xBB 0xBF as the first 3 bytes
Ah, right you are. I saw the familiar
[Tue Aug 02 11:32:15.966414 2016] [cgi:error] [pid 2255] [client 127.0.0.1:59312] End of script output before headers: perlinfo.pl
and completely missed seeing a few lines up
[Tue Aug 02 11:32:15.966191 2016] [cgi:error] [pid 2255] [client 127.0.0.1:59312] AH01215: Can’t locate HTML/Perlinfo.pm in @INC (you may need to install the HTML::Perlinfo module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.22.1 /usr/local/share/perl/5.22.1 /usr/lib/x86_64-linux-gnu/perl5/5.22 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.22 /usr/share/perl/5.22 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base .) at /home/www/cgi-bin/perlinfo.pl line 5.: /home/www/cgi-bin/perlinfo.pl
it couldn’t have been a much better error message than that
Also, while cpan still works for what you need, cpanminus is regarded a superior replacement.
Also, if you want to use a different version of Perl without breaking sysperl, please use something like PerlBrew or plenv, which makes keeping track of perl versions and local libraries much easier.
As for these examples; please keep in mind that modules like CGI are deprecated in the Perl core, and that you are very much recommended to use PSGI via the use of Plack.
There are middleware packages for Plack::Handler::Apache2 if you’re required to use Apache; otherwise there are servers like Starman that you can place behind Apache2 or Nginx and just proxy through.
Hope that helps!
Have you tried downloading the file you created via nano and using a program like WinMerge to compare it to your local echo.pl file to see what differences it can find?
Not yet, but it’s worth a try.
This is what I got with WinMerge. Same number of characters, looks like an empty line at the end of the working file (on the left), and the comment at the bottom of each pane that one came from Unix and the other from Windows.
Okay, now install Notepad++ (if you don’t have it already), and open the Unix file and the Windows file in it.
Then go to View > Show Symbol > Show All Characters.
You should see something similar to (for Unix)
And for the Windows version
Then on the Windows version, choose Edit > EOL Conversion > Unix Format
Save the file and FTP it to your server to see if it works.
I think we’re nearly there. I got the Windows created version of the very simple file to run by following the steps you outlined. Hurray!
Moving swiftly on, I tried it on the actual file I need to work with, but it’s still toilet time and the “End of script output before headers” message.
On a bit of whim though, I compared the encoding of the working file (UTF-8) with the failing echo.pl (UTF-8-BOM). I switched it over to UTF-8 and [FANFARE PLEASE!]
.
.
.
Ladies and Gentlemen… The Eagle has landed…
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.
