ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject RE: cvs commit: jakarta-ant .cvsignore
Date Tue, 28 Nov 2000 07:32:17 GMT
At 04:17  27/11/00 -0800, you wrote:
>> From: Peter Donald []
>> 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 ;)



| "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               |

View raw message