ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 28874] - Execute class has buggy patchEnvironment() implementation
Date Wed, 16 May 2007 20:21:14 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=28874>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28874





------- Additional Comments From mark_melvin@amis.com  2007-05-16 13:21 -------
This is nice that you tried to fix this for Ant 1.7 but I think you have made 
things worse than before - especially for people that have inserted ugly 
workarounds.  For example, to ensure I had augmented any existing PATH 
environment variable values before on Windows I would have inserted the 
following into my Ant scripts:

<exec ...
  <env key="Path" value="new\paths;${env.Path}" />
  <env key="PATH" value="new\paths;${env.PATH}" />

This would have covered my butt before, augmenting the PATH whether it happened 
to be defined as "Path" or "PATH" in my current Windows environment.

However - my builds all broke in Ant 1.7.  It took me quite a while to figure 
out why, but it looks like it is due to this bugfix.  It appears that the 
bugfix was only implemented for the "setting" of environment variables.  For 
instance, on Windows XP my path is defined as "Path".  If I read my environment 
into the property "env", then ${env.Path} gives me my actual path and 
${env.PATH} is not defined at all!  However, if I execute my Ant snippet above 
(which is in all my build scripts as a workaround), I end up setting my path 
correctly with the first <env> key and then hosing it with the second one.

Obviously it is impractical to set a property for every case combination of 
every environment variable, but how are we supposed to know which case is even 
set?  If I am interested in getting the path in my build script, how do I know 
if it is "Path" or "PATH"?  Now I have to do something like this:

<property environment="env"/>
<condition property="env.brandNewPath" value="${env.Path}">
  <isset property="env.Path" />
</condition>
<condition property="env.brandNewPath" value="${env.PATH}">
  <isset property="env.PATH" />
</condition>

<exec ...
  <env key="Path" value="new\paths;${env.brandNewPath}" />


I'm not sure if there is a good solution to this problem at all.  However, I 
like the idea of an optional boolean that was proposed in Comment #1.  At least 
then you are explicitly turning this behaviour on.  Perhaps a boolean that 
forces all environment variables to be uppercase in the <property> task would 
be a good solution?  Something like:

<property environment="env" forceuppercase="true" />

Or perhaps we can get an "append" or "prepend" attribute on the <env> element 
that will do the right case-insensitive thing when setting a variable?

I dunno.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message