Re^3: Using FastCGI

What error did it cause? I just tested the following code:

my @found = grep { -f && /\.pl/ } @array;
[download]

... and it did work.

You are probably not invoking the script from within the working directory. If you have proper permissions, you can 'chdir', or you could specify the full path like this:

my @files = 
    grep { -f && /^parsed.*\.txt$/ }
    map  { "$dir/$_" } 
    readdir($dh);
[download]

A subtle change. From an efficiency standpoint, *slightly* worse, as map now acts on every item returned by readdir. But on the other hand, it works if your path is not your current directory. Besides, even if your directory has a thousand files in it, the map and grep aren't costing you much time. Again, this is where profiling comes in. :)

Look at the CPAN module Devel::Profile.

Dave

Comment on Re^3: Using FastCGI Select or Download Code

Replies are listed 'Best First'.
Re^4: Using FastCGI by jonc (Beadle) on Jun 15, 2011 at 05:19 UTC
Well the issue is the screen prints blank or internal error. I guess one big problem I'm having is that I run the script to a local server to check. Is there a way to use Terminal?? I tried adding '-debug' at the end of use CGI, but that didn't work. I've also heard of the error log, but not sure how to easily see it. The files are in a different directory. The script is in my cgi-bin. I guess -f only works on current directory? Thanks for helping me understand this Dave	[reply]
Re^5: Using FastCGI by davido (Cardinal) on Jun 15, 2011 at 05:30 UTC
Oh that's right, I forgot we're dealing with CGI. Your system administrator would be able to tell you where the webserver's error logs are. You'll need to check them for the specific error. On my system they're in /var/log/apache2/ and the file I look at is error.log. I also have a symlink to the apache logfile path in my home directory at ~/web/apache2logs for convenience (that keeps them close to where I do my work). You may also be able to use the CPAN module CGI::Carp with its fatalsToBrowser() function, but that's for development, usually not production (you usually don't want an error message going to the browser that everyone can see, particularly if it exposes details about your server or script). -f works on the current directory, or on a full path, or on a relative path (relative to the current working directory). But whatever $dir path works for you for opening the files, it will also work for you with the -f test, so that snippet of code I posted in my previous response should set you straight if my theory is accurate as to why it's failing. But without seeing the error it's just a theory. Dave	[reply]