Return-Path: 
 <dev-return-9758-apmail-perl-dev-archive=perl.apache.org@perl.apache.org>
Delivered-To: apmail-perl-dev-archive@www.apache.org
Received: (qmail 74080 invoked from network); 16 Dec 2004 20:27:50 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur-2.apache.org with SMTP; 16 Dec 2004 20:27:50 -0000
Received: (qmail 38943 invoked by uid 500); 16 Dec 2004 20:27:49 -0000
Delivered-To: apmail-perl-dev-archive@perl.apache.org
Received: (qmail 38927 invoked by uid 500); 16 Dec 2004 20:27:49 -0000
Mailing-List: contact dev-help@perl.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@perl.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@perl.apache.org>
list-post: <mailto:dev@perl.apache.org>
Delivered-To: mailing list dev@perl.apache.org
Received: (qmail 38908 invoked by uid 99); 16 Dec 2004 20:27:49 -0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Received: from giga.umi.com (HELO giga.umi.com) (192.195.245.143)
  by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 16 Dec 2004 12:25:48 -0800
Received: from [127.0.0.1] (leszczynski_l.bos.il.pqe [172.24.74.211])
	by giga.umi.com (8.12.10/8.12.10) with ESMTP id iBGKPOl7024895;
	Thu, 16 Dec 2004 15:25:24 -0500
Date: Thu, 16 Dec 2004 15:25:24 -0500 (Eastern Standard Time)
From: Larry Leszczynski <larryl@emailplus.org>
To: dev@perl.apache.org
cc: Stas Bekman <stas@stason.org>
Subject: Re: [mp2 bug] Perl*Env issues
In-Reply-To: <41C0A91C.90305@stason.org>
Message-ID: <Pine.WNT.4.58.0412161341420.2928@LESZCZYNSKI_L.bos.il.pqe>
References: <9212531d04121409477e77d35@mail.gmail.com>
  <41BF83C1.5080300@stason.org>
 <9212531d04121500132c59b8f4@mail.gmail.com> <41C0A91C.90305@stason.org>
X-X-Sender: larryl@emailplus.org@mail.messagingengine.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

Hi Stas -

> I propose the following "simple" solution:
>
> 1) Keep %ENV intact at the server startup, so anything set in the shell is
> seen from perl
> 2) PerlPassEnv and PerlSetEnv aren't run yet but postponed to until after
> post_config.
> 3) just before starting workers, detach %ENV from environ, cleaning it up
> completely. now run PerlPassEnv and PerlSetEnv from (2)
>
> That way we don't have to deal with the painful timing of PerlPassEnv and
> PerlSetEnv. We simply document that those have an affect *only*
> post-post_config phase, i.e. starting from child_init phase. If someone
> wants to modify %ENV as it's seen from shell, they can just do that with
> <Perl> sections.

I like it a lot, it should be easy for people to understand the flow.

Just want to make sure I understand something:  I think in #3 above when
you say "cleaning it up completely", you mean cleaning up environ
completely (so workers don't inherit) but keeping %ENV available for
PerlPassEnv, right?  So I should be able to do something like this:

   (assume shell env has PATH and INSTANCE variables set)

   <Perl>
      $ENV{PATH} = $ENV{INSTANCE} eq 'development'
                   ? "$ENV{PATH}:/extra/devl/path/needed/by/my/modules"
                   : "$ENV{PATH}:/extra/prod/path/needed/by/my/modules";
   </Perl>

   PerlPassEnv PATH

   (now worker %ENV contains modified PATH, but not INSTANCE)


Yes?


Thanks,
Larry Leszczynski






---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org