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

[Diane Holt <ho...@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? 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.

Diane



=====
(holtdl@yahoo.com)



__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

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

[Peter Donald <do...@apache.org>]

At 05:46  28/11/00 -0800, you wrote:
>--- 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?

anytime you place a <env> tag you require the environment as Java wipes the
env variables clean instead of adding to them. So anytime an Exec task uses
env you would need to find the existing environment and then add changes
applied by <env> tag.

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

just don't specify <env/> subelements or else we can add an attribute that
will not force load the environment.

>And is <exec> the only task this would effect? 

pretty much - Unless you inherit/use exec target and change env elements.

>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). 

right.

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

umm - well in theory it will not brake any current files ... unless you
rely on  <env/> subelements and their being a "clean" environment (An
extremely rare thing). In which case you can just set the attribute that
saids don't auotcheck ;)

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