> 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. Jose Alberto
