Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <635802DA64D4D31190D500508B9B04104E0FC0@dcsrv0>
From: Jose  Alberto Fernandez <JFernandez@viquity.com>
To: "'ant-dev@jakarta.apache.org'" <ant-dev@jakarta.apache.org>
Subject: RE: cvs commit: jakarta-ant .cvsignore
Date: Tue, 28 Nov 2000 13:33:38 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

> From: Peter Donald [mailto:donaldp@apache.org]
> 
> 
> At 04:17  27/11/00 -0800, you wrote:
> >> From: Peter Donald [mailto:donaldp@apache.org]
> >> 
> >> At 12:22  27/11/00 -0800, you wrote:
> >> >This reminds me that there is a pending "BUG", in my opinion, with
> >> >respect to the <exec*> tasks and their definition of nested <env>.
> >> >Today, <env> replaces ALL environment variables with the 
> >> ones specified,
> >> >which is USELESS to say the least.
> >> >
> >> >There was some discussion in the past on how to overcome 
> >> this. It was not
> >> >preaty, and it was not cheap, but it definetely was possible. 
> >> >I think we should look at this again.
> >> 
> >> The problem is win9x platform. What would be ideal is to grab 
> >> all shell
> >> variables and place them as system properties (ie. TERM -> 
> >> env.TERM). This
> >> is easily doable on unix and I was told it was possible on 
> >> winNT/2000. 
> >> 
> >
> >I thought the "cmd /c set" returns the value of ALL environment
> >variables in ALL Windows systems. Is that no so?
> >It is not preaty, but executing that and parsing the output is
> >all that is needed.
> 
> I didn't know that. It is "command /c set" under win9x. I 
> guess what we
> have to do is "%CMD% /c set > ant-env.tmp" (where %CMD% is 
> command or cmd)
> and then pass this file to ant via a command line parameter. 
> ... Hmm may
> hack this togther a bit later ... unless you want to do it ;)
> 
> 

What I was planning was defining a task that uses <exec> to get this
information. Of course there is this little issue of %CMD% but I guess
there has to be be a way arround it.

So, I am proposing two things:

1) Define a task <procenv prefix="prefix" /> this will execute the command
for the particular OS and define properties for each of the envvariables
whose names will be prefixed with the specified prefix:

   <procenv prefix="ant.env" />
 you will have ant.env.CLASSPATH, ant.env.PATH, etc.

2) Modify <exec*> so that when <env> element is used, it first collects
the current environment, and sends it over, but changing any <env> being
specified. I coud add a noenv="true" the the tasks to allow for not
inheriting anything. But the default would be noenv=false.

3) The environment will be cached so only the first time any of these things

are called, it will be actually computed.

Jose Alberto