You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Jesse Glick <Je...@netbeans.com> on 2000/08/08 22:18:29 UTC
[PATCH] make Execute take advantage of 1.3's CWD support
The attached patch (only lightly tested and only on Linux, please note)
should make ExecTask/Execute (<exec>) take advantage of JDK 1.3's new
Runtime.exec accepting a working directory, thus avoiding the need to
use antRun. It should also correct a bug in ExecTask that antRun was
used even when no 'dir' attribute was given (the working directory did
not need to be set at all). And hopefully the code should be a little
clearer (all the alternative strategies are listed in order in one
method).
Previous code had this:
private static String antWorkingDirectory =
(new File((new File(".")).getAbsolutePath())).getParent();
(Written by Mariusz.) I've replaced that with
System.getProperty("user.dir") which is defined from JDK 1.1 to give the
intended result, so hopefully the older code was not a workaround for an
obscure broken JDK.
Two other thoughts about using antRun (not antRun.bat, only the POSIX
version):
1. At least on Bash and I thought other Bourne shells, $@ should be "$@"
to preserve spaces correctly, I think. (But why <<echo $CMD $@ | sh>>
instead of simply <<exec $CMD $@>> or better <<exec "$CMD" "$@">>?)
2. If /bin/sh is found to exist at runtime, why not use it rather than
rely on some shell script? Take the command array cmdl, then construct a
new one of three strings: "/bin/sh", "-c", and then: "cd
${workingDirectory}; " plus each element of cmdl, separated by spaces,
surrounded by ticks ('), and properly escaped (' -> '"'"'). Is there
something special antRun does beyond this?
-Jesse
--
Jesse Glick <ma...@netbeans.com>
NetBeans, Open APIs <http://www.netbeans.org/>
tel (+4202) 3300-9161 Sun Micro x49161 Praha CR
Re: Exec basedir problem
Posted by Stefan Bodewig <bo...@bost.de>.
I'm still thinking too Unix centric I guess.
I wanted to make the argument processor smart enough to accept
everything an experienced Unix user could do and only generate output
that works on all platforms. I've come to understand that there is no
way to meet goal 1 without breaking funtionality on DOS based
platforms.
On Unix you can do
<command a\ b> or <command "a b"> or <command 'a b'> to have exactly
one argument for cammand. On Windows the first version has a totally
different meaning.
Should be fixed now, I have removed the special meaning of \
characters inside command lines.
Stefan
Exec basedir problem
Posted by David Forslund <dw...@lanl.gov>.
I'm running an exec task (jidl) to build the appropriate java code for my
application from idl. I'm seeing
a problem with the basedir being passed in and how it is interpreted on
WinNT. The basedir
being passed in is correct and of the form: e:\project. When an argument
is created from this
basedir and passed as an argument to exec the backslashes are removed
resulting in an incorrect
argument (verified by the -verbose flag). How can I avoid this happening,
that is interpreting the backslash
as an explicit quote of the next character.
Thanks,
David W. Forslund dwf@lanl.gov
Advanced Computing Laboratory http://www.acl.lanl.gov/~dwf
Los Alamos National Laboratory Los Alamos, NM 87545
505-665-1907 FAX: 505-665-4939
Re: [PATCH] make Execute take advantage of 1.3's CWD support
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "JG" == Jesse Glick <Je...@netbeans.com> writes:
JG> However, if the "dir" attribute is simply omitted, then it does
JG> not make any attempt to change the working directory with the
JG> understanding that you don't care--if you need the command to be
JG> run in any particular directory, you should pass e.g. dir=".". I
JG> presume you intend that a missing dir should instead equal
JG> dir="." and that this is why you did not commit the change to
JG> ExecTask.
I don't think anybody has defined it this way or the other. Your
interpretation might be even closer to the intent of the original
authors (dir was listed as a required attribute in the docs, but this
was not enforced by the task).
What do others think? If the user omits the dir attribute, does that
mean "I don't care" or "use basedir"?
JG> Stefan Bodewig wrote:
>> I'm not sure, that user.dir holds an absolute path on every JDK. I
>> hope it does
JG> I hope so too...if it does *not* hold an absolute path, then it
JG> would be pretty tautological.
True.
Stefan
Re: [PATCH] make Execute take advantage of 1.3's CWD support
Posted by Jesse Glick <Je...@netbeans.com>.
Stefan Bodewig wrote:
> 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.
Yes, that is sort of what I meant to say. The behavior in my patch is (I
hope) that it resolves the supplied working directory (if any) relative
to the project as usual, and if the result is the same as the current VM
cwd, then it skips trying to change the path (because it is already
there).
However, if the "dir" attribute is simply omitted, then it does not make
any attempt to change the working directory with the understanding that
you don't care--if you need the command to be run in any particular
directory, you should pass e.g. dir=".". I presume you intend that a
missing dir should instead equal dir="." and that this is why you did
not commit the change to ExecTask.
> 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.
I hope so too...if it does *not* hold an absolute path, then it would be
pretty tautological.
-Jesse
--
Jesse Glick <ma...@netbeans.com>
NetBeans, Open APIs <http://www.netbeans.org/>
tel (+4202) 3300-9161 Sun Micro x49161 Praha CR
Re: [PATCH] make Execute take advantage of 1.3's CWD support
Posted by Barrie Treloar <Ba...@camtech.com.au>.
On 9 Aug 2000, Stefan Bodewig wrote:
> 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?
+1 for me. Exec should be using the path setting.
Barrie
--
Barrie Treloar
____________________________________________________________________
Barrie Treloar Phone: +61 8 8303 3300
Senior Analyst/Programmer Fax: +61 8 8303 4403
Electronic Commerce Division Email: barrie@camtech.com.au
Camtech (SA) Pty Ltd http://www.camtech.com.au
--- Level 8, 10 Pulteney Street, Adelaide SA 5000, Australia. ---
____________________________________________________________________
Re: [PATCH] make Execute take advantage of 1.3's CWD support
Posted by Mariusz Nowostawski <ma...@marni.otago.ac.nz>.
On 9 Aug 2000, Stefan Bodewig wrote:
> >>>>> "JG" == Jesse Glick <Je...@netbeans.com> 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.
I agree with Stefan here.
> 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?
No objections.
I will have a look at the current "exec"-related stuff and will test it
today or tommorrow, I promise ;o)
Re: [PATCH] make Execute take advantage of 1.3's CWD support
Posted by Stefan Bodewig <bo...@bost.de>.
Thanks for the patch Jesse.
>>>>> "JG" == Jesse Glick <Je...@netbeans.com> 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