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