in reply to Re: Using FastCGI
in thread Using FastCGI

Oh, well this was an amazing help. Should I include my full code? It seemed like a lot to post, so I omitted it.

grep { -f && /^parsed.*\.txt$/ caused an error, so I used  grep { '-f' && /^parsed.*\.txt$/} with single quotes, until this is tested, I just won't check if it's a file.

Your post definitely gave me hope that I can find a way to optimize the rest of the script. I was really impressed by the use of $/ to eliminate so much. I hope I can begin to think that way. It may help to amalgamate all the files into one before hand to avoid that one loop

Thanks!

Replies are listed 'Best First'.
Re^3: Using FastCGI
by davido (Cardinal) on Jun 15, 2011 at 04:53 UTC

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

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

    ... 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);

    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

      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

        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