ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Devienne" <ddevie...@gmail.com>
Subject Re: svn commit: r446979 - in /ant/core/trunk: CONTRIBUTORS WHATSNEW contributors.xml src/main/org/apache/tools/ant/taskdefs/Execute.java
Date Mon, 18 Sep 2006 14:45:23 GMT
> 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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message