Side effect of JDK 1.5.0._05. Ant command line parse failure
Roedy Green
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.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.
Roedy Green
<loo...@mindprod.com.invalid> wrote or quoted :
>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.
--
__________
|im |yler http://timtyler.org/ t...@tt1lock.org Remove lock to reply.
Tim Tyler
> In comp.lang.java.programmer Roedy Green <loo...@mindprod.com.invalid> wrote or quoted:
> > 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
<loo...@mindprod.com.invalid> wrote or quoted :
>
>[-cp]
>[.;C:\;E:" zip]
I reverted to JDK 1.5.0_04 and the problem is STILL there. What the
heck?
Oliver Wong
"Roedy Green" <loo...@mindprod.com.invalid> wrote in message
news:iau0j119djdadeuie...@4ax.com...
> On Tue, 20 Sep 2005 19:37:07 GMT, Roedy Green
> <loo...@mindprod.com.invalid> wrote or quoted :
>
>>
>>[-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
"Oliver Wong" <ow...@castortech.com> wrote in message
news:Dd%Xe.180249$wr.123210@clgrps12...
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
<loo...@mindprod.com.invalid> wrote or quoted :
>
>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
<loo...@mindprod.com.invalid> wrote or quoted :
>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
--
Unemployed English Java programmer
http://jroller.com/page/tackline/
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
<henry.t...@not.here> wrote or quoted :
>
>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
> On Tue, 20 Sep 2005 20:07:51 -0400, Henry Townsend
> >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.
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
>On Tue, 20 Sep 2005 20:07:51 -0400, Henry Townsend
><henry.t...@not.here> wrote or quoted :
>
>>
>>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.
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
wrote or quoted :
>CP/M also used forward slash.
/ = forward slash
\ = backward slash
David Segall
>On Wed, 21 Sep 2005 08:32:42 GMT, David Segall <da...@nowhere.net>
>wrote or quoted :
>
>>CP/M also used forward slash.
> / = forward slash
>\ = backward slash
Woops! Of course I should have written "CP/M also used backward slash"
Eric Jacoboni
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.
--
Jaco
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
> Roedy Green wrote:
>
>>
>> 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.
That is correct, but good luck getting anybody else to believe you. :-)
Ray
--
XML is the programmer's duct tape.