Thanks for the patch Jesse.
>>>>> "JG" == Jesse Glick <[EMAIL PROTECTED]> writes:
JG> It should also correct a bug in ExecTask that antRun was used
JG> even when no 'dir' attribute was given (the working directory did
JG> not need to be set at all).
Here I disagree.
Whenever we specify a file or directory, we assume them to be relative
to the project's basedir. Following this line of thought I interpret a
missing dir attribute as "use the basedir" - which may very well be
something other than user.dir. If it happens to be the same, we don't
change the directory anyway.
JG> Previous code had this:
JG> private static String antWorkingDirectory = (new File((new
File(".")).getAbsolutePath())).getParent();
JG> (Written by Mariusz.) I've replaced that with
JG> System.getProperty("user.dir") which is defined from JDK 1.1 to
JG> give the intended result, so hopefully the older code was not a
JG> workaround for an obscure broken JDK.
Actually you have to blame me, not Mariusz. I'm not sure, that
user.dir holds an absolute path on every JDK. I hope it does - as I've
commited you patch.
JG> Two other thoughts about using antRun (not antRun.bat, only the
JG> POSIX version):
I hadn't looked into the script before - I'd like to add another
point:
If I happen to have a script /tmp/ls.sh, antRun will invoke this
script instead of /usr/bin/ls for
<exec dir="/tmp" executable="ls" />
which is not what I'd expect - quite the opposite, there is a reason I
don't have . in my PATH.
Any objections against dropping this behavior?
Stefan
