You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Shimon Rura <sr...@carsinfo.com> on 2000/08/07 22:45:56 UTC
script-specific environment variables?
Hi,
I'm working on updating some disgusting hack CGI scripts to use mod_perl and
DBI. The database backend is Informix, but the web structure is designed to
allow accessing different database configurations from different virtual
hosts. For example, http://dev:9040/ might be integrated with the main
working database, while http://dev:9041/ works with a testing or training
database. This separation is crucial in development and client use.
Unfortunately, Informix and one of our own libraries depends on environment
variables to distinguish this connection information (there is probably a
workaround for DBD::Informix but our library is bad painful legacy code with
awful and immutable API). Therefore, I need to set environment variables,
but the settings need to be somehow localized for each script.
The obvious solution is to put a bunch of assignments to $ENV{'blah'} at the
top of each script. This strikes me as rather ugly though, and forces our
developers to type more.
PerlSetEnv is almost a solution; its failing is that is doesn't fake scope
for environment variables (not that it should). If I could put PerlSetEnv
directives inside of <VirtualHost> or <Location> tags for Apache, and that
forced scoping upon them, that would be perfect.
Perhaps there is some way I can actually use reasonable Perl scoping to set
a variable in the scope of a Virtual Host? If so, then I could just specify
a hash of environment variables called %myEnv in each <VirtualHost> or
<Location> section, and the web scripts could just call a single function
like envImport(%myEnv) at the top. That would be great, as all
virtualHost-specific configuration would exist in Apache configuration
files.
The only other alternative I can think of is to store these settings in a
file and call a function to parse the local configuration file for each
script request. This seems to add a lot of overhead though. Files suck.
Any solutions from the mod_perl gurus out there?
Thanks,
Shimon Rura
CARS Information Systems, Cincinnati, OH
Re: script-specific environment variables?
Posted by Perrin Harkins <pe...@primenet.com>.
On Mon, 7 Aug 2000, Shimon Rura wrote:
> Perhaps there is some way I can actually use reasonable Perl scoping to set
> a variable in the scope of a Virtual Host? If so, then I could just specify
> a hash of environment variables called %myEnv in each <VirtualHost> or
> <Location> section, and the web scripts could just call a single function
> like envImport(%myEnv) at the top. That would be great, as all
> virtualHost-specific configuration would exist in Apache configuration
> files.
Put all of your variables itnto a multi-level hash that loads before the
fork in startup.pl:
my %HostEnv = (
'host1' => { 'db-user' => 'goofball'},
'host2' => { 'db-user' => 'cherryblintz'}
);
Then you can use PerlSetVar to put the key for each group of settings
inside a VirtualHost or Location. Your import function just looks up the
PerlSetVar value with $r->dir_config() and uses it as a key to get the
settings from the global hash %HostEnv.
- Perrin
Re: script-specific environment variables?
Posted by Stas Bekman <st...@stason.org>.
On Mon, 7 Aug 2000, Shimon Rura wrote:
> Hi,
>
> I'm working on updating some disgusting hack CGI scripts to use mod_perl and
> DBI. The database backend is Informix, but the web structure is designed to
> allow accessing different database configurations from different virtual
> hosts. For example, http://dev:9040/ might be integrated with the main
> working database, while http://dev:9041/ works with a testing or training
> database. This separation is crucial in development and client use.
>
> Unfortunately, Informix and one of our own libraries depends on environment
> variables to distinguish this connection information (there is probably a
> workaround for DBD::Informix but our library is bad painful legacy code with
> awful and immutable API). Therefore, I need to set environment variables,
> but the settings need to be somehow localized for each script.
>
> The obvious solution is to put a bunch of assignments to $ENV{'blah'} at the
> top of each script. This strikes me as rather ugly though, and forces our
> developers to type more.
>
> PerlSetEnv is almost a solution; its failing is that is doesn't fake scope
> for environment variables (not that it should). If I could put PerlSetEnv
> directives inside of <VirtualHost> or <Location> tags for Apache, and that
> forced scoping upon them, that would be perfect.
>
> Perhaps there is some way I can actually use reasonable Perl scoping to set
> a variable in the scope of a Virtual Host? If so, then I could just specify
> a hash of environment variables called %myEnv in each <VirtualHost> or
> <Location> section, and the web scripts could just call a single function
> like envImport(%myEnv) at the top. That would be great, as all
> virtualHost-specific configuration would exist in Apache configuration
> files.
>
> The only other alternative I can think of is to store these settings in a
> file and call a function to parse the local configuration file for each
> script request. This seems to add a lot of overhead though. Files suck.
>
> Any solutions from the mod_perl gurus out there?
How about creating vars scoped in packages and then building ENV vars from
the in the script. e.g:
evironment_packages.pl
----------------------
package My::script::foo
my %env = (FOO => 1, BAR => 2);
package My::script::bar
my %env = (FOO => 22, BAR => 55);
1;
loading this file at the server startup and then in the script:
1. figure out the name of the script (path or whatever you prefer,
e.g. __PACKAGE__)
2. build the package name using 1. so it'd comply with the above packages
3. use() this package
4. copy the %package::whatever::env into local %ENV
So the code that you will have to add won't be different from script to
script. Of course you can mangle the Apache::Registry and add this code
only once inside it without touching the scripts.
If you do that, you better inherit from Apache::RegistryNG and do whatever
you want to extend the functionality.
Voila
I'm sure there is a bunch of other more creative solutions...
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perlmonth.com perl.org apache.org