RE: Picking up the environment (was: RE: cvs commit: jakarta-ant .cvsignore)

[Jose Alberto Fernandez <JF...@viquity.com>]

> From: Diane Holt [mailto:holtdl@yahoo.com]
> 
> --- Peter Donald <do...@apache.org> wrote:
> > Perhaps we may even execute the task automagically in exec. So if a
> > particular exec call requires the environment you 
> auotmatically execute
> > procenv?
> 
> How would you see specifying that the <exec> requires the environment?
> Maybe with an attribute? I'm all for being able to access 
> environment vars
> on demand, but I'd be reluctant to not have a way to also not 
> have them
> accessed. And is <exec> the only task this would effect? 

1) Today's <exec*> passes the environment by default UNLESS
you try to modify it, in which case it only passes what you say.
(This is the JVM behavior, not ANTs).

2) So the behavioral change will only affect usage of <exec*> that
use nested <env> declarations, and I would add an attribute to
control that.

> Since moving to
> Ant, I've been pretty much leaving the user environment 
> behind, and just
> depending on either command-line properties (passed by the 
> wrapper-script
> or by the user) or properties files -- that way, being in an "ant
> environment" doesn't really mess with the user's environment 
> much at all
> (other than to add ANT_HOME and some dirs to PATH). So I'd need to
> re-think some things if the user's env was going to be 
> re-introduced into
> the mix on some wide scale.
>

There is nothing that says that you need to abandon what you are
doing. In particular because usage of environment variables will
not be cheap you need to crate a subprocess to get at it.

On the other hand, I do not think it is right to have to modify
the shell or BAT file for ANT in order to get to that info when
needed.

Jose Alberto