Thanks for the comments, it is always nice for people
to check the code - I mentioned that this patch was
the one that I was a little worried about.
And thanks to you for all the work in BugZilla! Impressive!!!
1)
The code does not export the lower case version
of the env variable that the user passed in, the
lower case version is only used for comparision
purposes.
Cool. I can't look at the whole code right now,
so was only going by the diff. I know that the app that
produces these emails includes a link to online diffs
when they are too large, instead of inline in the mail,
but having a link all the time would be valuable IMHO.
<echo>Path is ${env.PATH}</echo>
In my experience, this is likely to fail to display the Path, since
it may not be spelled PATH, but Path, or path, etc...
That's why I had a custom <binaryConfig> task that loaded the
name and value of the path in two ptys: os.path.name and os.path.
Allowed me to write cross-platform builds much more easily. That
task defined other ptys like os.libpath.name and os.libpath, etc...
For example, on Windows, os.libpath.name contained "Path"
(or "PATH", or whatever the current form of this guy), but on Linux
it was LD_LIBRARY_PATH.
The one thing that is infurating is that "Path" can be "PATH" or "path"
or whatever is the whim of the windows machine, and
it is difficult to write an ant script that work correctly
when using <property environment="env"/>,
I know. That's why I created that <binaryConfig> task.
perhaps we could provide a touppercase=yes/no option to
<property environment="env">, or provide
a "${getenv:} prefix to ${} expansion to correspond
to java(1.1-, 5+) System.getenv(key).
Why not. That could be handy. We have yet to officialize and document
this mechanism though, no?
Note that getenv() is case-insensitive:
<target name="beanshell">
<script language="beanshell">
System.out.println(System.getenv ("pAth"));
</script>
</target>
Didn't know that.
One change that could be made would be
to ignore the casiness of the key in the <env key="">
and use the casiness of the key in the current env, it is present.
Yes, this would correspond precisely to what I was doing. I'm +1 to this.
I was using for example, to prepend ${basedir}/bin to the path, the following
code: <env key="${os.path.name}" path="${basedir}/bin;${os.path}" />
It doesn't solve though the case (upper or lower, or mix) with which
you must refer to the var using the ${env.xyz} property notation.
Unless we add an attribute to <property env>, as you mention, to force
the names to lower or upper case. (combined with the change you
described above. The two are be linked). Otherwise you can't know
whether to use ${env.PATH} or ${env.Path}, etc...
--DD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
