The module you have problems with is really called "Config.pm" or is this just an example?
Just an example. It could be anything - Field.pm, etc.
Next question is ... is the working directory what you think it is? I believe some versions of IIS used to set the working directory to the web root, not to the directory containing the script!
We're running Apache on some unix-flavor.
In either case your modules should not be in the web accessible directories, it's better to have them outside the cgi-bin.
This is a fine workaround, I was hoping that there was something else - or at least a better understanding of why perl is even looking in these directories.
There are many popular packages that put perl modules in the cgi-bin. Moveable Type comes to mind.
| [reply] |
#!perl
use Cwd;
print "Content-type: text/plain\r\n\r\n";
print "Cwd=".cwd()."\n";
print "\@INC=('" . join("', '", @INC)."')\n";
eval "use lib qw(./lib);";
print "\@INC after use lib=('" . join("', '", @INC)."')\n";
eval "use Field;";
if ($@) {
print "Failed to use Field.pm: $@\n";
} else {
print "Field.pm loaded from $ENV{'Field.pm'}\n";
}
The reason why you should not put the modules in cgi-bin is that you most likely do not want people to download or execute them, do you? If your scripts are to be installed in $foo/cgi-bin then the libraried may well be in $foo/lib. Thus you'd just use lib qw(../lib); instead. Or maybe rather use Cwd;use lib cwd()."/../lib"; to be safe in case you change the working directory and try to import some more modules later.
| [reply]
[d/l]
[select] |
OK then, what does this script print?
Sadly, I don't have access to this particular server, and particular hosting account. I'm trying to answer the questions of a user of mine. They've basically given up on my program, because of the FrontPage problem. I can't be the only person having this problem with perl scripts/programs they distribute. Thought I'd start my homework here, after doing the obligatory google search, which didn't really give me any leads.
The reason why you should not put the modules in cgi-bin is that you most likely do not want people to download or execute them, do you? If your scripts are to be installed in $foo/cgi-bin then the libraried may well be in $foo/lib. Thus you'd just use lib qw(../lib); instead.
In my experience, any file that doesn't have a fileending of, ".pl", or, ".cgi", that's located in the cgi-bin, doesn't get executed as a cgi script. This is ultimately based on the Apache (in this case) server config.
That's one safegaurd.
Another is the lack of a shebang line in perl modules - what is the server supposed to run the file as? Usually on the first line (instead of the shebang line), you declare the name of the perl module itself, correct? Something like:
package FooBar;
Thirdly, cgi scripts usually have to have their permissions changed to 755 to execute through the web browser.
What usually happens when you visit a perl module in a browser, is that you get a Server 500 error. I have seen, in rare circumstances (let's say, .01%), the sourcecode of the package itself get printed out. But, since this program is open source, let the code be free! :) Your example of using Cwd may move the lib dir into the public html directory. Usually apache is set up to map any unknown filetype to a text/plain mime type - which means, you'll def. see the sourcecode. Also, I don't think you can call use like your example shows:
use Cwd;use lib cwd()."/../lib";
perhaps:
use Cwd;
require lib cwd()."/../lib";
Looking for the current working directory also doesn't turn up what you expect in cgi scripts. I know the, $ENV{HOME} variable is usually not given.
I may be wrong.
If any and all these safegaurds fail, on Apache servers (the target platform, again), usually an .htaccess file, with:
deny from all
in the lib directory will do the trick.
Or, am I missing something else?
Finally, I look at the London Perl Mongers effort on the nms-scripts program - which, as they state, is a rewrite of poorly written cgi scripts, done by professionals, with security def. in mind. They've consciously used their efforts to show how perl cgi scripts are supposed to be written.
As just one example, I looked at a program called, "TFMail", which is a basic form handler, and a replacement for the ubiquitous, "FormMail.pl" script.
It's a simple program, that does use outside .pm perl packages to get its job done. the location of these packages can be set in the program itself. The documentation of the program does state (emphasis mine)
You must also copy NMStreq.pm and MIME_Lite.pm to the server. You should put them in the location that you configured for LIBDIR above.
Leaving LIBDIR set to '.' and uploading the .pm files into your cgi-bin directory will work on most UNIX systems.
So, it doesn't seem like these self-proclaimed professionals (of which are undoubtably much smarter than I am), don't see much of a problem. If you see a problem, you may want to tell them they have a bug on their hands.
So, I think I make a good argument for the placement of Perl packages in a cgi-bin. I'm having trouble with FrontPage making strange directories and weird configuration files, with the same names of the perl packages and mucking up my program. And, I'm looking for a workaround (moving them out of the cgi-bin is something I already stated in the initial post, I think)
Sorry if I've come off like I don't know what I'm doing - I don't have any formal training, but Perl was made to hack, as I was lead to believe, and it's lead me to work as well as I can, from what I know with it. I've got a few years under my belt, but I feel like I'm being replied to as if I haven't a clue and this prentension just saddens me, because it doesn't do much for the popularity of Perl.
| [reply]
[d/l]
[select] |
No, skazat, the wisdom Jenda ofered is not "a fine workaround."
Rather, it is "best practice," SOP and/or doctrine.
| [reply] |
Can you tell me why it's a bad practice? I'm willing to listen.
And if it's a bad practice, can you give me an example of a better way to package a perl script that uses outside modules, without having to explicitly set the perllib path? Many of my users have a great deal of trouble getting over that very hump.
| [reply] |
