CGI scripts and modular design?
psyshrike
I've been poking through some different shopping cart software, trying
to decide which one to use. All of them use piped filehandles or
backticks to handle modularization.
I will be modifying my store with some very custom requirements. It
will be about a dozen modules before it is complete.
My question is, Is there are reason why CGI scripts don't:
use lib "./lib" ;
and use modular code instead of backticking everything? My virtual
hosting ISP permits calling locally installed libraries. Is it common
practice for ISP's to not allow this? If I use modular design am I
hurting my portability if I decide to go with another webhosting
service?
I have the hardest darned time sorting through the bazillion scripts
in my cgi-bin. If I can't come up with a reason not to, I am turning
half of them into object libraries, and sticking them in /cgi-bin/lib
The only reason I can think of for not doing this is executable size.
If memory is quota'd this could be a problem. The quota would have to
be pretty anemic to be a factor though.
Comments? Recomendations?
Can other folks confirm that they do this too?
-Thanks in advance
-Matt
Matt S Trout
psyshrike <shr...@cyberspace.org> wrote:
>Howdy,
>
>I've been poking through some different shopping cart software, trying
>to decide which one to use. All of them use piped filehandles or
>backticks to handle modularization.
>
>I will be modifying my store with some very custom requirements. It
>will be about a dozen modules before it is complete.
>
>My question is, Is there are reason why CGI scripts don't:
>
>use lib "./lib" ;
>
>and use modular code instead of backticking everything? My virtual
>hosting ISP permits calling locally installed libraries. Is it common
>practice for ISP's to not allow this? If I use modular design am I
>hurting my portability if I decide to go with another webhosting
>service?
Possibly, if their webserver is configured to execute scripts with an absolute
path.
>I have the hardest darned time sorting through the bazillion scripts
>in my cgi-bin. If I can't come up with a reason not to, I am turning
>half of them into object libraries, and sticking them in /cgi-bin/lib
No, definitely do this.
>Comments? Recomendations?
Try at the top of your scripts -
BEGIN {
$location = $ENV{'SCRIPT_FILENAME'};
$location =~ s!/[^/]+$!! || $location = '.';
unshift(@INC,"${location}/lib");
};
That seems to cater nicely for such things - if you're called with an absolute
path it'll push <path>/lib into the include list, if not it'll add './lib'.
Also, because it does an unshift on @INC you'll get modules in your lib before
ones in the main perl tree, which means you can "upgrade" stuff by copying your
own version in, at least for pure perl modules.
--
Today's proposed addition to the PDP-11 instruction set:
EPI Execute Programmer Immediately
Today's fatal mistake:
#include <pi-syspkt.h> [ My homepage is http://www.trout.me.uk ]
Gunnar Hjalmarsson
> My question is, Is there are reason why CGI scripts don't:
>
> use lib "./lib" ;
>
> and use modular code instead of backticking everything?
The authors learned Perl 10 years ago?
What you say is of course not true for all CGI scripts. There is no
reason for you to not apply Perl 5 style and incorporate code via modules.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
John Bokma
news:79485f9d.04092...@posting.google.com:
> Howdy,
>
> I've been poking through some different shopping cart software, trying
> to decide which one to use. All of them use piped filehandles or
> backticks to handle modularization.
>
> I will be modifying my store with some very custom requirements. It
> will be about a dozen modules before it is complete.
>
> My question is, Is there are reason why CGI scripts don't:
>
> use lib "./lib" ;
What is . ? I remember that there was (is?) no guarantee that it's the
cwd of your script. You can use FindBin to solve this problem though.
> and use modular code instead of backticking everything? My virtual
> hosting ISP permits calling locally installed libraries. Is it common
> practice for ISP's to not allow this?
Some don't give shell access.
> If I use modular design am I
> hurting my portability if I decide to go with another webhosting
> service?
There is so much choice in webhosting those days that it's not that
difficult to find one that meets your requirements.
--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
Scott W Gifford
[...]
> I have the hardest darned time sorting through the bazillion scripts
> in my cgi-bin. If I can't come up with a reason not to, I am turning
> half of them into object libraries, and sticking them in /cgi-bin/lib
Sticking them in cgi-bin/lib might make them directly executable,
depending on Web server configuration, which may not be what you want
(especially if including the file has side-effects).
I usually create a cgi-lib directory outside of the Web server's root,
and put all CGI libraries in there. That way they can't be read or
executed directly by the Web server.
I sometimes also set the PERL5LIB environment variable in Apache to
specify where my libraries are, then use this code to untaint it and
pull it in:
BEGIN {
if ($ENV{PERL5LIB} and $ENV{PERL5LIB} =~ /^(.*)$/)
{
# Blindly untaint. Taintchecking is to protect from Web data;
# the environment is under our control.
eval "use lib '$_';"
foreach (reverse split(/:/,$1));
}
}
That makes it easier to use the same script in different locations, by
just changing the Apache config (with .htaccess if you don't control
the entire server).
Overall, this is a very good idea. It should make your code easier to
maintain, encourage you to re-use code, and ensure that when you fix a
bug in one place it is fixed everywhere.
-----ScottG.
Gunnar Hjalmarsson
>> My virtual hosting ISP permits calling locally installed
>> libraries. Is it common practice for ISP's to not allow this?
>
> Some don't give shell access.
Assuming we are talking about pure Perl modules, why would you need
shell access to upload them to a local library?
Possible providers who permit that you run your own CGI scripts
written in Perl, but don't 'permit' the use of own modules, are
ignorant and not worth to take into consideration.
John Bokma
berlin.de:
> John Bokma wrote:
>>> My virtual hosting ISP permits calling locally installed
>>> libraries. Is it common practice for ISP's to not allow this?
>>
>> Some don't give shell access.
>
> Assuming we are talking about pure Perl modules, why would you need
> shell access to upload them to a local library?
make? Unless you have exact the same environment as your hosting provider.
There was a time I developed stuff on IRIX :-D
> Possible providers who permit that you run your own CGI scripts
> written in Perl, but don't 'permit' the use of own modules, are
> ignorant and not worth to take into consideration.
Sometimes you can get a "shell" via CGI :-D, but I prefer the real thing.
Gunnar Hjalmarsson
> Gunnar Hjalmarsson wrote:
>> John Bokma wrote:
>>> Some don't give shell access.
>>
>> Assuming we are talking about pure Perl modules, why would you
>> need shell access to upload them to a local library?
>
> make?
Okay, but make isn't necessary. Simply uploading the .pm files to the
right directories is sufficient. I did that successfully for several
years as long as I had a hosting account without shell access.
John Bokma
berlin.de:
> John Bokma wrote:
>> Gunnar Hjalmarsson wrote:
>>> John Bokma wrote:
>>>> Some don't give shell access.
>>>
>>> Assuming we are talking about pure Perl modules, why would you
>>> need shell access to upload them to a local library?
>>
>> make?
>
> Okay, but make isn't necessary. Simply uploading the .pm files to the
> right directories is sufficient. I did that successfully for several
> years as long as I had a hosting account without shell access.
If it's pure Perl, ok. But when you need a C compiler... And let's hope you
can access that one. Otherwise you need access to the same OS, or worse
depending on how you link.