At 04:17 27/11/00 -0800, you wrote: >> From: Peter Donald [mailto:[EMAIL PROTECTED] >> >> 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 ;) 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 | *-----------------------------------------------------*
