ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject RE: cvs commit: jakarta-ant .cvsignore
Date Wed, 29 Nov 2000 00:35:05 GMT
At 01:33  28/11/00 -0800, you wrote:
>> 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.

+ 1000000 ;)

Perhaps we may even execute the task automagically in exec. So if a
particular exec call requires the environment you auotmatically execute
procenv? 

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*


Mime
View raw message