Side effect of JDK 1.5.0._05. Ant command line parse failure

[Roedy Green]

Ever since I installed JDK 1.5.0_05 ant seems to ignore anything on
the command line. it ignores -debug or targets.

The ant.bat file is unchanged. I have invoked ant.bat explicitly in
case one other ant.bat appeared on the path without success.

I can get ant to run any target by modifying the default inside the
build.xml. It appears to be a command line problem.

The line that ant.bat generates looks like this:

"E:\program files\java\jdk1.5.0_05\bin\java.exe" -classpath
"e:\apache-ant-1.6.5\lib\ant-launcher.jar"
"-Dant.home=e:\apache-ant-1.6.5" org.apache.tools.ant.launch.Launcher
-cp ".;C:\;E:\" zip

where zip is the name of my target

I did a diagnostic and discovered that ant thinks the java classpath
has two elements, mistaking my zip target for part of the classpath.
this indicates there may be some change in command line processing in
the new Java version.


java.class.path : e:\apache-ant-1.6.5\lib\ant-launcher.jar;C:\com
tcard\.\;C:\;E:\apache-ant-1.6.5\bin\" zip;E:\apache-ant-1.6.5\;...

I found that reversing the order of the parms now makes Ant work

"E:\program files\java\jdk1.5.0_05\bin\java.exe" -classpath
"e:\apache-ant-1.6.5\lib\ant-launcher.jar"
"-Dant.home=e:\apache-ant-1.6.5" org.apache.tools.ant.launch.Launcher
zip -cp ".;C:\;E:\"

where zip is my target.

 

[Roedy Green]

I did a diagnostic and discovered that ant thinks the java classpath
has two elements, mistaking my zip target for part of the classpath.
this indicates there may be some change in command line processing in
the new Java version.

I have now demonstrated the fault lies not with ANT but with JDK
1.5.0_05.

Here my test program

All it does in dump the command line args in [] so you can see
lead/trail spaces.

/** test command line parsing */
public class CommandLine
{
/**
* test harness
*
* @param args not used
*/
public static void main ( String[] args )
{
for ( String s: args )
{
System.out.println( "[" + s + "]" );
}
}
}


Here is a sample command line:

"E:\program files\java\jdk1.5.0_05\bin\java.exe" -classpath C:\exper
CommandLine -cp ".;C:\;E:\" zip

Here is the output:

[-cp]
[.;C:\;E:" zip]

Totally screwed up. It stripped one " but not the other. It glued to
parms together. It threw away a \.

Looks like someone was attempting to create a consistent quoting
scheme and screwed up on backward compatibility.

 

[Tim Tyler]

Here is a sample command line:

"E:\program files\java\jdk1.5.0_05\bin\java.exe" -classpath C:\exper
CommandLine -cp ".;C:\;E:\" zip

Here is the output:

[-cp]
[.;C:\;E:" zip]

Totally screwed up. It stripped one " but not the other. It glued to
parms together. It threw away a \.

Looks like someone was attempting to create a consistent quoting
scheme and screwed up on backward compatibility.

It looks as though "\" is now being treated as an escape character:

\; is a semicolon - and \" is a quote. There's no close quote
matching the open one - and so the quotes are still mismatched
at the end of the word "zip"

No doubt replacing "\" with "\\" would resolve things.

 

[Tim Tyler]

Here is a sample command line:

"E:\program files\java\jdk1.5.0_05\bin\java.exe" -classpath C:\exper
CommandLine -cp ".;C:\;E:\" zip

Here is the output:

[-cp]
[.;C:\;E:" zip]

Totally screwed up. It stripped one " but not the other. It glued to
parms together. It threw away a \.

Looks like someone was attempting to create a consistent quoting
scheme and screwed up on backward compatibility.

It looks as though "\" is now being treated as an escape character:

\; is a semicolon - and \" is a quote. There's no close quote
matching the open one - and so the quotes are still mismatched
at the end of the word "zip"

On that theory, practically all Windows path handling of command line
parameters would be screwed. Maybe it's only when the path is quoted.

 

[Roedy Green]

[-cp]
[.;C:\;E:" zip]

I reverted to JDK 1.5.0_04 and the problem is STILL there. What the
heck?

 

[Oliver Wong]

[-cp]
[.;C:\;E:" zip]

I reverted to JDK 1.5.0_04 and the problem is STILL there. What the
heck?

Tried it on JDK 1.5.0_02 and the problem happens there too.

- Oliver

 

[Oliver Wong]

[-cp]
[.;C:\;E:" zip]

I reverted to JDK 1.5.0_04 and the problem is STILL there. What the
heck?

Tried it on JDK 1.5.0_02 and the problem happens there too.

Tried it again on JDK 1.5.0, and the problem happens there as well.

Incidentally, the javadoc in your test program is misleading,
particularly the part that says "args not used".

- Oliver

 

[Roedy Green]

Here is a sample command line:

"E:\program files\java\jdk1.5.0_05\bin\java.exe" -classpath C:\exper
CommandLine -cp ".;C:\;E:\" zip

Here is the output:

[-cp]
[.;C:\;E:" zip]

Mystery solved. That is apparently normal behaviour. I am surprised I
have not tripped over this until today.

I have written my findings at http://mindprod.com/jgloss/main.html


Command Line

The arguments that main gets passed are the result of the both the
command processor and the Java runtime cooking the command line. I
strongly suggest dumping the parameters out surrounded in [] if you
are in the least suspicious the parameters you are getting are not
what you expect. The command processor does macro expansion (% in
Windows), and wildcard expansion so that *.html becomes a list of
individual files or directories matching the pattern.

The Java run time splits the command line parameters at spaces, except
for parameters enclosed in quotes. It preserves the spaces inside the
quotes, and strips the quotes. The Java runtime treats quotes
literally that are preceded by \. The rule seems to be \ is treated
literally, except when you have a string of \ before a " then \ means
the next \ is taken literally, but if the next character is a " then
that quote is taken literally. I have never seen a stranger quoting
scheme.
Command Line Quoting Scheme in Windows

To Get You must type Notes

E:\Program Files "E:\Program Files" You must surround the
parameter in quotes if it contains a space.

E:\Program Files\ "E:\Program Files\\" You must double a
trailing \, but not embedded ones.

E:\Program Files\\ "E:\Program Files\\\\" You must double each
trailing backslash, but not embedded ones.

E:\Program Files\\\ "E:\Program Files\\\\\\" You must
double each trailing backslash, but not embedded ones.

E:\\Program Files "E:\\Program Files" Don't need to double
multiple embedded \s either.

E:\\\Program Files "E:\\\Program Files" Don't need to double
multiple embedded \s either.

E:\Program Files" "E:\Program Files\" Not that you would
ever want this. This in what happens if you carelessly have a single
trailing \ on your parameter. This is very common in windows. It means
a directory.

a " character "a \" character" Parameters with embedded
quotes must be preceded by a \.

a \" character "a \\\" character" to get an embedded literal \
then " you need \\\"

One practical consequence of this is you should do your utmost to
avoid a \ at the end of any parameter or set parameter, particularly a
path or classpath. The penalty for failing to this will be for example
that ant can't understand any arguments you pass to it because its
command line parsing is screwed up by the trailing \ when it
mindlessly uses macro expansion of the classpath on its command line.

Unfortunately trailing backslashes occur frequently in Windows, to
describe drives, directories, especially in paths and classpaths.

 

[Roedy Green]

Unfortunately trailing backslashes occur frequently in Windows, to
describe drives, directories, especially in paths and classpaths.

Given that \ is such a frequently used character in Windows it was
not a good idea to snaffle it as a quoting character. It would have
been better to just double up " I would be curious to find out how
command line quoting works on other platforms. If it is the same, the
use of \ is not so problematic since on other platforms, / is use in
filenames.

Has anyone ever seen any documentation on this?

 

[Thomas Hawtin]

what you expect. The command processor does macro expansion (% in
Windows), and wildcard expansion so that *.html becomes a list of
individual files or directories matching the pattern.

It's been nine years since I programmed for Windows, but my recollection
was that it was up to the program to expand wildcards. I don't think
notepad did so. C and Java programs by default have some code between
WinMain and main to perform some manipulations.

The Java run time splits the command line parameters at spaces, except
for parameters enclosed in quotes. It preserves the spaces inside the
quotes, and strips the quotes. The Java runtime treats quotes
literally that are preceded by \. The rule seems to be \ is treated
literally, except when you have a string of \ before a " then \ means
the next \ is taken literally, but if the next character is a " then
that quote is taken literally. I have never seen a stranger quoting
scheme.

Java does something similar. \u is treated specially. Bloch and Gafter's
Java Puzzlers, puzzle 15 has the example:

/**
* Generated by the IBM IDL-to-Java compiler, version 1.0
* from F:\TestRoot\apps\a1\units\include\PolicyHome.idl
* Wednesday, June 17, 1998 6:44:40 o'clock AM GMT+00:00
*/

Tom Hawtin

 

[Henry Townsend]

Given that \ is such a frequently used character in Windows it was
not a good idea to snaffle it as a quoting character.

I think you have it precisely backwards from an historical perspective;
given that \ was so widely used as a quoting character for decades
before Windows existed, it was not a good idea to snaffle it for a path
separator.

 

[Roedy Green]

I think you have it precisely backwards from an historical perspective;
given that \ was so widely used as a quoting character for decades
before Windows existed, it was not a good idea to snaffle it for a path
separator.

Windows/DOS was just trying to make it not so obvious what a rip off
they were from CPM/86.

 

[Tim Tyler]

Windows/DOS was just trying to make it not so obvious what a rip off
they were from CPM/86.

These days Windows programmers have to deal with spaces in file names.

I think Microsoft are simply prone to screwing this sort of stuff up.

 

[David Segall]

Windows/DOS was just trying to make it not so obvious what a rip off
they were from CPM/86.

CP/M also used forward slash. I think the problem stemmed from the
fact that CP/M followed the DEC operating system convention of using /
as an option delimiter and by the time they introduced a directory
tree full stop and colon also had a special meaning.

 

[Roedy Green]

CP/M also used forward slash.

/ = forward slash
\ = backward slash

 

[David Segall]

/ = forward slash
\ = backward slash

Woops! Of course I should have written "CP/M also used backward slash"

 

[Eric Jacoboni]

Woops! Of course I should have written "CP/M also used backward slash"

I don't understand... As far i remember, CP/M didn't have directories features.

Also, CP/M is born after Unix (which was developped around mid 60's to
early 70's) : at this time, \ was already known to be THE escape
character in both shell and C.

In fact, it seems MS choose \ as path separator because DOS 1 already
has choosen / for command options.

 

[Tim Tyler]

CP/M also used forward slash. I think the problem stemmed from the
fact that CP/M followed the DEC operating system convention of using /
as an option delimiter and by the time they introduced a directory
tree full stop and colon also had a special meaning.

The sad story:

http://www.seasip.demon.co.uk/Cpm/optchar.html

 

[Raymond DeCampo]

It's been nine years since I programmed for Windows, but my recollection
was that it was up to the program to expand wildcards. I don't think
notepad did so. C and Java programs by default have some code between
WinMain and main to perform some manipulations.

That is correct, but good luck getting anybody else to believe you.

Ray