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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
