Keeping track of scripts and where their files are expected to be is proving painful. Installation and update is proving painful.

Make a standard. It really doesn't matter much what it is, but just having a standard you follow will make your maintenence much simpler.

Here is what I do. You don't have to do this, but I like and it seems to work well :

/www
    /project_name
        /html
        /cgi
        /lib
        /conf
        /images
        /tmp #if needed
[download]

If you don't standardize you layout, it's quite easy to make a simple mistake that exposes your 'lib' or 'conf' files. You'll get into the habit of not including these directories in your httpd.conf and all you really need to when progamming is  use lib '../lib/';

Then make a simple script to create your standard layout. You can even include some starter scripts with some standard modules like Template Toolkit or CGI::Application, ...

One way around that would be to install everything in one directory outside the Web server's area, then use symlinks to link in the parts that should be available on the Web.

Another way is to put all support files in a subdirectory, and put a .htaccess file that will block access (though that will only work under Apache).

Yet another way is to have a smart installer run one time via the Web, which will figure out where things should go and put them there, then disable itself. I've seen that approach used before, most often in PHP scripts, and it makes it very easy to get things installed quickly.

Another way is to put all support files in a subdirectory, and put a .htaccess file that will block access (though that will only work under Apache).

...And only if .htaccess is turned on to begin with.

Ah, yes. I should have mentioned that I am (or at least *think* I am!) controlling access to the directories through Apache conf.

Thanks for making that clear :-)

Good question. I have the following layout, more or less inherited from the original developer (Hi Mike), but something that makes good sense to me:

/--|
   /code--|
          /bin
          /lib
          /web--|
                /html--|
                       /images
                /cgi-bin
                /templates
          /utilbin
    /conf
    /data
    /logs
    /run
    /setup
[download]

Inside the code directory, the bin and lib directories are programs and libraries that the web application will use; there's a web directory that holds the static HTML pages (with a sub for images), the CGIs and the templates for the dynamic pages. The utilbin directory is for programs that are associated with the web application but that will usually be run from the command line -- sort of like an sbin for the application, I suppose.

Outside of the code directory I have directories for configuration files, data, log files, PID files and one for installation files.

An application that I'm in the process of developing uses the same directory structure, with the difference that below the templates directory I have two more directories, html and yaml, based on whether I'm outputing HTML web pages or YAML objects for the REST interface.

I like to have more, rather than less directories. I don't like to have everything in one directory -- yes, it's easy to find things, up to a point, then it starts to get hard to find things again.

It seems to work well enough. :-)