I have a perl cgi file that works fine. However, I want to move it into a sub directory -- the cgi-bin directory for Apache HTTPD is just getting too crowded.
I know that feeling...
So I created a directory and moved my file. It could not find my evidence_db.pm file (which defined variables like $sCssRoot that contain the paths to my cascading style sheet directory). So I added the command use "../" and this lib statement solved one problem.
Generally all lower case module descriptions are used for pragmas, with all upper case used for top level groupings, you may want to switch to a mixed case module name...
However, as I mentioned, I also have js (javascript) and css (cascading style sheet) files that work in the top level directory but don't work now. Is there a way I can painless move files around in directories?
In general no. The 'use lib qw()' is really a Perl specific mechanism for adding a directory to @INC for Perl's module search path, so has nothing to do with CSS, Javascript, or the web in general. To go along with this is that generally code runs out of a cgi-bin which is inherently different than a regular htdocs directory, and may be on a completely different server than where the CSS is served from, and since these types of files are client side they need to have a relative or absolute URL path as opposed to file system path like the Perl libs. Now having said that, if your css/js files are served from a path that stays the same with respect to your program then the use of FindBin might provide an easy way to manipulate all three at once:
perldoc FindBin
Here is my source code:
<snip source>
After all of that, I generally keep my css and js in top level directories off the root of the server, so that I can reference them very easily in *all* scripts no matter the depth within my cgi-bin by using a plain slash, so....
/cgi-bin/folder/script.pl /cgi-bin/lib /htdocs/styles /htdocs/js /htdocs/some/random/page.htm
In script.pl when I print the location of the css, my variable (actually I use a constant) I simply need '/styles' in that location, so that when the code actually comes out it has an absolute path for the URL. The same goes for the js.
Although this isn't entirely true either, as recently I have gone really insane (as drieux warned me against, sorry drieux), and decided to run several sites out of the same code base, so my directory structure actually looks like:
/domains/lib
/domains/forms
/domains/formats
/domains/styles
/domains/danconia/cgi-bin
/domains/danconia/lib
/domains/danconia/htdocs
/domains/danconia/htdocs/styles (this directory contains symbolic links to the base level styles I need in all domains, yikes)
/domains/danconia/htdocs/js
/domains/danconia/htdocs/images
/domains/danconia/formats
/domains/danconia/forms
Then to add another domain I add the 2nd level directory structure starting at 'danconia'... edit one config file that just stores a bunch of constants and I am ready to roll... In each of the scripts I then have a use lib line that references first the specific domain lib directory and second the main lib directory so that I can override for any specific domain any specific Perl lib. For instance a top level script has at the top:
use FindBin; use lib "$FindBin::Bin/../../lib"; use lib "$FindBin::Bin/../lib";
A second level script merely adds a '../' to each, and so on....I have considered using the same symlink mechanism for the cgi scripts themselves, but at current they represent a minimum of the code (as most of it is in modules in the top 'lib' anyways) and may change more frequently on a per site basis (though I am starting to question that).
Hopefully this does less scarying you, and more showing you that the possiblities are virtually endless, but you need to keep in mind the difference between a local filesystem and URLs.
HAND,
http://danconia.org
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
