Re^2: Running in Terminal, but not on Server

Thanks for the hints, I will try to fix them, unfortunately, I can't use Perl/CGI modules as I don't know how to install them (Everything is on a server, no remote terminal, just a cPanel)

For the use strict; parameter, everytime I use it, my script give me an internal error when put on the server, so I never put it :(.

Hmm and it would have been nice if it would be that, I thought the same thing first, but there's 2 line inside, and in that case, I can trust the value of split for the opened files as they are all recorded the same way, for each line, via perl. But yeah of course, I will need to verify the one made from the browser.

It still doesn't work, but thanks for the help, at least I will be able to make it more secure. =)

Comment on Re^2: Running in Terminal, but not on Server

Replies are listed 'Best First'.
Re^3: Running in Terminal, but not on Server by moritz (Cardinal) on Jan 24, 2008 at 23:18 UTC
CGI is shipped with perl since perl 5.4, which is more than ten years old - chances are that CGI.pm is already installed. As for the debugging, try `use CGI::Carp qw(fatalsToBrowser);` as your first line of code - it will print error messages to the browser. (And yes, CGI::Carp is also a core module since perl 5.4). If you can't even access core modules, then either find another server to work on, or chose a different language. Perl without modules really sucks, compared to other languages with modules/libs. And btw there is cgipan, which installs CPAN modules via CGI ;-)	[reply] [d/l]
Re^4: Running in Terminal, but not on Server by ShaZe (Novice) on Jan 24, 2008 at 23:36 UTC
Ok, I tryed what you said, to find out that what you said was true, Carp is a core module so the fuction as worked. Very useful, I can now know everything that goes wrong, there's even a message that write my email to report the error message, pretty nice. Otherwise, I found what it is.... The file can't be found, you had 50% of the answer. This is probably because the directory that got the files is protected with chmod and maybe something else, htaccess. It's a little bit normal because it is a forum. But I was sure that the server could use it for itself.... as hes the owner of thoses files.... So now, I really don't know what to do... I will maybe try to play with the chmods, but I don't want to create new security hole... Hmm and wasn't the script suppose to tell me that it was not able to open it with the die information?.. Well, thanks a lots for everything I leanred, I will try to see what I can do with that. There's probably a way, because the forum is also in perl, and it always create and modify files. Gotta try a few things. Thank!	[reply]
Re^5: Running in Terminal, but not on Server by cdarke (Prior) on Jan 25, 2008 at 03:16 UTC
Hmm and wasn't the script suppose to tell me that it was not able to open it with the die information?.. Read the reply given by moritz again, particularly the bit about `use CGI::Carp qw(fatalsToBrowser);`	[reply] [d/l]
Re: Running in Terminal, but not on Server by ShaZe (Novice) on Jan 25, 2008 at 04:49 UTC
Aww, I almost give up, I don't understand why it doesn't want to open that file. I tryed to put it in read mode, and anyway, the folders accept to be read, but not to be written, so it should work... I also tryed to put absolute URL, or starting the path from the root. Nothing Work. The program just don't want to open it.	[reply]
Re^2: Running in Terminal, but not on Server by Corion (Patriarch) on Jan 25, 2008 at 07:08 UTC
If you are using `open my $fh, $file or die "Can't open '$file': $!";`, then you will have at least the error message, and when fighting with permissions, most likely the error message is right. Remember that your webserver may be running your program with a different user and a different "current directory" than your terminal session, so your approach of using absolute filenames is very correct. I guess the main problem is that your file is not readable for the webserver user. I suggest that you change the permissions to one file to be world-readable (via `chmod ugo+r this_one_file.txt`) and then check again, and if that still fails, slowly work your way up, making directories world-readable (via `chmod ugo+rx that_directory`). Making things world-readable is OK if you planned to serve all data via the internet anyway, but it's stupid if you plan to keep that data hidden, hence, be careful in what you make world readable.	[reply] [d/l] [select]