problem with commandlines

[Brian Leonard <br...@brainslug.org>]

I started to build one of the other Jakarta projects when it puked at the
javadoc section.  I've tracked it down to the fact that arguments with
spaces in them don't get quoted, so things like docTitle="Test Arg" confuse
javadoc (and I'm assuming every other command that parses args the same
way).  I'm guessing this isn't a problem on windows, but my unix machine
doesn't like it.

Seems they should be quoted in
  ... types.Commandline.Argument.setValue(String)
The toString() method of Commandline does the right thing, but it never gets
called.  I'd be happy to add it myself, as I could just steal what's there
already in toString().

-bl

Re: problem with commandlines

[Stefan Bodewig <bo...@bost.de>]

>>>>> "CW" == Cory Wandling <co...@ObjectDynamics.com> writes:

 CW> But the user must still specify the command line as a single line
 CW> and so there is still a basic problem with embedded spaces.

Quite the opposite is true with current CVS. You are going to get a
deprecation warning for the command attribute of <exec>. The preferred
way is to say

<exec executable="command">
  <arg value="value that contains spaces" />
  <arg line="value that shall be splitted like the OS would do" />
  <arg path="some;string:treated;as:a;path" />
  <arg file="relative/name/resolved/to/an/absolute/path/by/Ant" />
</exec>

Stefan

Re: problem with commandlines

[Cory Wandling <co...@ObjectDynamics.com>]

But the user must still specify the command line as a single line and so
there is still a basic problem with embedded spaces.  If we could have tags
for each parameter then embedded spaced would not be a problem.  True, this
would break a lot of code and so a different task is needed. Then one could
begin a migration of existing tasks that are using the single command line.

Cory Wandling
Object Dynamics, Inc.

He is no fool who gives up that which he cannot keep - Jim Elliot


----- Original Message -----
From: Stefan Bodewig <bo...@bost.de>
To: <an...@jakarta.apache.org>
Sent: Thursday, August 10, 2000 10:09 AM
Subject: Re: problem with commandlines


> >>>>> "CW" == Cory Wandling <co...@ObjectDynamics.com> writes:
>
>  CW> When I have built things like this I have always used the
>  CW> String[] version of exec.
>
> This is what the current (CVS) exec task does.
>
> The problem comes in when we need to change the working directory of
> the spawned process. JDK 1.3 has a method to do this (and we use it,
> thanks Jesse), the Mac seems to handle this if we set user.dir. On
> Win9x and Unix we use a shell script, this one gets the parameters via
> the String[] call but doesn't quote the correctly when invoking the
> desired command.
>
> Stefan

Re: problem with commandlines

[Stefan Bodewig <bo...@bost.de>]

>>>>> "CW" == Cory Wandling <co...@ObjectDynamics.com> writes:

 CW> When I have built things like this I have always used the
 CW> String[] version of exec.

This is what the current (CVS) exec task does.

The problem comes in when we need to change the working directory of
the spawned process. JDK 1.3 has a method to do this (and we use it,
thanks Jesse), the Mac seems to handle this if we set user.dir. On
Win9x and Unix we use a shell script, this one gets the parameters via
the String[] call but doesn't quote the correctly when invoking the
desired command.

Stefan

Re: problem with commandlines

[Cory Wandling <co...@ObjectDynamics.com>]

When I have built things like this I have always used the String[] version
of exec.  Otherwise you have to do what the command line processors on the
OS do - parse looking for quotes and divide the command line up into a
String[].

Are you or someone else planning on redoing the Exec task?

Cory Wandling
Object Dynamics, Inc.

----- Original Message -----
From: Stefan Bodewig <bo...@bost.de>
To: <an...@jakarta.apache.org>
Sent: Thursday, August 10, 2000 2:45 AM
Subject: Re: problem with commandlines


> >>>>> "BL" == Brian Leonard <br...@brainslug.org> writes:
>
>  BL> Seems they should be quoted in
>  BL> ... types.Commandline.Argument.setValue(String)
>
> No, the issue seems to be more difficult than that. The arguments are
> passed to the subprocess as a String[] and everything you add via
> setValue will take exactly one slot in this array.
>
> If I run the attached ExecArray class on Linux, I get
>
> bodewig@sbodewig ~/jakarta/jakarta-ant >java ExecArray
> Arg 0: 1
> Arg 1: 2
> Arg 2: 3
> Arg 0: 1
> Arg 1: 2 3
> Arg 0: 1
> Arg 1: "2 3"
>
> on Windows NT the result is
>
> bodewig@sbodewig ~/jakarta/jakarta-ant >java ExecArray
> Arg 0: 1
> Arg 1: 2
> Arg 2: 3
> Arg 0: 1
> Arg 1: 2 3
> Arg 0: 1
> Arg 1: 2 3
>
> you see, exactly two arguments are passed to the subprocess - if I use
> quotes around them or not doesn't matter. But I surely don't want the
> quotes to become a literal part of my argument as I would on Linux
> (and this is the correct behavior IMHO) - so I can not blindly add
> quotes.
>
> >From this little experiment I'd say the invoked process is doing
> something wrong with the arguments, not Ant. Maybe the problem lies in
> the antRun scripts?
>
> Anybody more Windows savvy than me, would the following change to
> antRun.bat solve the problem on Win95/98?
>
> ! set PARAMS=%PARAMS% %1
> ! set PARAMS=%PARAMS% "%1"
>
> I'm going to look into the sh version.
>
> Stefan
>
>

Re: problem with commandlines

[Stefan Bodewig <bo...@bost.de>]

The antRun scripts really cause the problems.

I've changed the Unix version, which also didn't work when the command
itself or the directory to change to contained spaces. Actually I
think we could drop antRun and invoke sh directly like the NT version
does with cmd - (as Jesse Glick has allready suggested). Do I miss
something here?

I don't know enough about DOS batch files to modify antRun.bat. Also,
does the NT version as it stand right now work or doe we need ro do
some additional magic?

Stefan

Re: problem with commandlines

[Stefan Bodewig <bo...@bost.de>]

>>>>> "BL" == Brian Leonard <br...@brainslug.org> writes:

 BL> Seems they should be quoted in
 BL> ... types.Commandline.Argument.setValue(String)

No, the issue seems to be more difficult than that. The arguments are
passed to the subprocess as a String[] and everything you add via
setValue will take exactly one slot in this array.

If I run the attached ExecArray class on Linux, I get

bodewig@sbodewig ~/jakarta/jakarta-ant >java ExecArray
Arg 0: 1
Arg 1: 2
Arg 2: 3
Arg 0: 1
Arg 1: 2 3
Arg 0: 1
Arg 1: "2 3"

on Windows NT the result is

bodewig@sbodewig ~/jakarta/jakarta-ant >java ExecArray
Arg 0: 1
Arg 1: 2
Arg 2: 3
Arg 0: 1
Arg 1: 2 3
Arg 0: 1
Arg 1: 2 3

you see, exactly two arguments are passed to the subprocess - if I use
quotes around them or not doesn't matter. But I surely don't want the
quotes to become a literal part of my argument as I would on Linux
(and this is the correct behavior IMHO) - so I can not blindly add
quotes.

RE: problem with commandlines

[Brian Leonard <br...@brainslug.org>]

> Try using single quotes around the value and then double quotes
> to take are
> of the imbedded space
>
> <exec dir=' "c:\This is a long file name"\file.txt' >
>

While that would probably work, I think it should be taken care of
automatically.  How many project authors are going to remember they need to
single quote certain elements?  Especially when those elements are used for
several purposes, one of which being as part of a command line.

-bl

Re: problem with commandlines

[Cory Wandling <co...@ObjectDynamics.com>]

Try using single quotes around the value and then double quotes to take are
of the imbedded space

<exec dir=' "c:\This is a long file name"\file.txt' >

----- Original Message -----
From: Brian Leonard <br...@brainslug.org>
To: <an...@jakarta.apache.org>
Sent: Wednesday, August 09, 2000 3:00 PM
Subject: problem with commandlines


> I started to build one of the other Jakarta projects when it puked at the
> javadoc section.  I've tracked it down to the fact that arguments with
> spaces in them don't get quoted, so things like docTitle="Test Arg"
confuse
> javadoc (and I'm assuming every other command that parses args the same
> way).  I'm guessing this isn't a problem on windows, but my unix machine
> doesn't like it.
>
> Seems they should be quoted in
>   ... types.Commandline.Argument.setValue(String)
> The toString() method of Commandline does the right thing, but it never
gets
> called.  I'd be happy to add it myself, as I could just steal what's there
> already in toString().
>
> -bl