DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6277>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6277 1.4.1 fails to execute my ant script when 1.3 does not [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |WONTFIX ------- Additional Comments From [EMAIL PROTECTED] 2002-05-31 14:07 ------- You do not need to define a CLASSPATH with quotes. It is possible to define an environment variable containing spaces in Windows and use it without requiring quotes. Try defining a classpath environment variable with spaces and no quotes, run Java and you will be able to load classes. So, in general, you do not need to use quotes to define and use an environment variable with spaces. You only need to quote an environment variable when you pass it as an argument on a command line. This is what Ant does in Ant 1.4 This did indeed change between Ant 1.3 and Ant 1.4 To understand why, please refer to http://nagoya.apache.org/bugzilla/show_bug.cgi?id=842 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2348 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2938 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3217 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5149 In fact there were many more problems without the surrounding quotes. As you'll see from the above bugs, a number of tools do not quote spaces in the classpath. I'm pretty sure the current behaviour is correct. The WHATSNEW for 1.4 said this: * Ant's wrapper scripts now quote the CLASSPATH environment variable, thus supporting classpaths which refer to directories containing spaces. This means that the CLASSPATH environment variable cannot have quotes. Any quotes should be removed. This will not affect the operation of the CLASSPATH environment variable in other contexts. I realize that this may not be compatible with other tools which take a different assumption. The current is, IMHO, the lesser of two evils. I'm going to mark as WONTFIX for this reason. BTW, probably worth mentioning when you have made a change to the scripts. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
