exporting Environment variables from mod_perl

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
Hi, all,

I'm wondering if anyone knows how to go about dealing with/working
around the following:

Normally the environment will propagate to processes called via
system, backticks or a pipe open. For instance:

use strict;
$ENV = "BAR";
open T, "perl test2.pl|";
print while <T>;
close T;

use strict;
for my $envar (sort keys %ENV) {
    print "$envar: $ENV\n";

If you run test1.pl, you will see that the environment variable
'AAA_FOO' is, in fact set according to test2.pl even though it was set
in test1.pl

Moreover, it's not ust perl magic. The following also works:

use strict;
$ENV = "BAR";
open T, "php test.php|";
print while <T>;
close T;

<!--#include virtual="/index_top.shtml" -->
<!--#include virtual="/index_bottom.shtml" -->

You'll see that AAA_FOO is again set.

But if I call these from inside a perl*Handler in mod_perl, this
behaviour doesn't happen:

use strict;

package Local::PHP;

sub handler {
    my $r = shift;

    unless (-s $ENV) {
<div>The PHP script you attempted to run was not found on this server.
Good day.</div>
        return Apache2::Const::NOT_FOUND;

    $ENV = "BAR";

    open PHP, "/usr/bin/php $ENV|"; # yes, I know
this isn't totally secure, it's just an experiment. Fix later.
    my $result = join '', (<PHP>);
    close PHP;

    $r->print($result || "attempt to run PHP script failed: $!");
    return Apache2::Const::OK;


Well, this doesn't work. The PHP script is called:
a) like a command line script because it doesn't know it's in the
server, so the whole thing comes out in text-only mode
b) without AAA_FOO or any other expected variables set (but weird ones

I tried to add:
    $r->subprocess_env($_, $ENV) for keys %ENV;

right after the place I set AAA_FOO

But that didn't work, either.

What I want is to be able to make the current environment set for the
called script from the pipe open. Not just PHP, it's just that by
being able to dump the environment, it's convenient to get to work
(though alternately, calling PHP like a CGI DOES enable me to use PHP
under a worker MPM without the security holes I keep hearing about
that make apt try to force apache to be prefork MPM just to add the

Anyway, any thoughts would be great! Thanks!


Re: exporting Environment variables from mod_perl

Dodger wrote:
Quoted text here. Click to load it
Quoted text here. Click to load it
When I want to be sure about right parameters passed to called script then I
never rely upon to environment data.
You can call other script by

open PHP, "/usr/bin/php $param1 $param2 $paramN |";

or you can use MySQL database with appropriate fields and
1. add row with needed data to table before you call other script
2. call script with single parameter (row ID, for example current proccess ID)
3. use these data in called script
4. delete the row after return to main script.
Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail.
Send me your mail from another non-spammer site please.)
Please reply to <petr AT practisoft DOT cz>

Re: exporting Environment variables from mod_perl

Dodger wrote:
Quoted text here. Click to load it

Why should it?

SCRIPT_FILENAME is a CGI variable, and you are not using CGI.  You are
still in the Web server.  You have to run a sub-process to run CGI.

There are mod_perl function to get the value of what
$ENV would be set to, so use that.

Quoted text here. Click to load it

You *might* not want that (sorry - all of my docs on mod_perl and env
stuff is at work, and I'm at home).  That would set the environment of
the Web server process, which is going to handle more requests than this
one - but Apache may clear this up anyway.
So you could open you own pipe handles and fork(), then setup the
environment you want (next para) on the child side only.

Anyway - you can do what you seem to want by calling a function called

Quoted text here. Click to load it

It's all in the mod_perl docs.   Go to:


and browse through the API calls for a function name that seems as
though it might be related to what you want and work onwards from there.

As hints for finding subprocess_env(),. I've assumed you are running
mod_perl2, are looking for the API, and what you want to do is related
to a Request record.

              Just because I've written it doesn't mean that
                   either you or I have to believe it.

Site Timeline