RE: FYI for Ant/Cygwin users -- Fundamental Change in the Behaviour of Cygpath in version 1.25

["Schaible, Jörg" <Jo...@gft.com>]

Hi Doug,

just modify the script to convert CLASSPATH only to UNIX if it contains a semicolon or a backslash. This will eliminate the problem. After running cygpath --unix we will not have any of these characters in the result.

Regards,
Jörg

-----Original Message-----
From: Newton, Doug [mailto:dnewton@twacs.com]
Sent: Tuesday, February 11, 2003 7:50 PM
To: 'user@ant.apache.org'
Subject: FYI for Ant/Cygwin users -- Fundamental Change in the Behaviour
of Cygpath in version 1.25
Importance: High


I just wanted to make all ant/cygwin users aware of a problem that I ran
into.  The following attached messages are from a thread I started on the
cygwin@cygwin.com mailing list about a "bug" in cygpath 1.25, which I first
noticed while running ant.

You can read the messages for the details, but here is short version:

On a cygwin platform, the ant shell script runs "cygpath --path --unix
$CLASSPATH".  This used to always return the unix format classpath
regardless of the format it started as.  Since cygpath version 1.25, if the
input classpath is a unix classpath of longer than 260 characters, it gets
truncated.  My build environment has a very long unix format classpath as
its starting point, so I started to occassionally get ClassNotFound
exceptions due to the truncated classpath.

The cygpath developer claims that this behaviour was intended.  I then
complained that it is a fundamental change in behaviour that people need to
know about and work around.  I don't know what the outcome will be, but I
just wanted to alert everyone to the potential problem.

If anyone wants to voice an opinion on the cygwin@cygwin.com mailing list,
it might have an effect on the resolution of this issue.

--Doug Newton
dnewton@htc.net

-----Original Message-----
From: Newton, Doug 
Sent: Tuesday, February 11, 2003 12:12 PM
To: 'cygwin@cygwin.com'; 'cgf-cygwin@cygwin.com'
Cc: 'dnewton@htc.net'
Subject: RE: cygpath bug in version 1.25 -- Fundamental Change in the
Behaviour of Cygpath
Importance: High


If this change is what is desired by the majority, that is fine.  BUT, it
should have been made clear that the fundamental behaviour of cygpath had
changed.  I have many scripts that no longer work.  Even the jakarata ant
tool's start-up script now mangles the classpath because of this change in
behaviour.

At least with version 1.21 (and I believe through 1.24, just glancing
through the CVS history), the behaviour was always as follows:

"cygpath --path --unix $UNIX_CLASSPATH" returns UNIX_CLASSPATH
"cygpath --path --unix $DOS_CLASSPATH" return UNIX_CLASSPATH
"cygpath --path --windows $UNIX_CLASSPATH" returns DOS_CLASSPATH
"cygpath --path --windows $DOS_CLASSPATH" returns DOS_CLASSPATH

Now the behaviour is as follows:

"cygpath --path --unix $UNIX_CLASSPATH" returns a truncated UNIX_CLASSPATH
if it is too long
"cygpath --path --unix $DOS_CLASSPATH" return UNIX_CLASSPATH
"cygpath --path --windows $UNIX_CLASSPATH" returns DOS_CLASSPATH
"cygpath --path --windows $DOS_CLASSPATH" returns a garbled DOS_CLASSPATH
regardless of length (e.g. the path is transformed from "C:/home/build" to
"C;c:/home/build"

We no longer have the option to run a classpath of unknown format through
cgypath to make sure it is in a known format.  This is the issue in the
jakarta ant tool.  It makes no assumptions on what the format of the path is
-- it immediately converts it to unix regardless of the current format.
This was the expected behaviour.

Is there another utility that can be used to identify the format of a
classpath?  This will be needed to account for the changed behaviour in
modifying scripts.

--Doug Newton
dnewton@htc.net

-----Original Message-----
From: Christopher Faylor [mailto:cgf-cygwin@cygwin.com]
Sent: Monday, February 10, 2003 9:04 PM
To: Newton, Doug
Subject: Re: cygpath bug in version 1.25


On Mon, Feb 10, 2003 at 05:29:32PM -0600, Newton, Doug wrote:
>I believe I have found a bug in cygpath.exe version 1.25 (Which has been
the
>version included since at least cygwin version 1.3.17-1 and through cygwin
>version 1.3.20-1).
>
>Using installations from any release since 1.3.17-1 (the earliest full
>installation that I had available), cygpath does work fine if converting a
>dos classpath to a unix classpath, and converting a unix classpath to a dos
>classpath.  BUT, if you try to convert a long unix classpath to a unix
>classpath, I have had truncation occur.

Correct.  You're passing a "windows path" to cygpath which consists of a
bunch of characters separated by colons.  cygpath is treating the input
as one filename so the path will be truncated to the maximum of 260
characters by cygpath.  That is by design.  Sorry.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


-----Original Message-----
From: Douglas Newton [mailto: dnewton@htc.net]
Sent: Monday, February 10, 2003 9:04 PM
To: cygwin@cygwin.com
Subject: Re: cygpath bug in version 1.25


I believe I have found a bug in cygpath.exe version 1.25 (Which has been the
version included since at least cygwin version 1.3.17-1 and through cygwin
version 1.3.20-1).

Using installations from any release since 1.3.17-1 (the earliest full
installation that I had available), cygpath does work fine if converting a
dos classpath to a unix classpath, and converting a unix classpath to a dos
classpath.  BUT, if you try to convert a long unix classpath to a unix
classpath, I have had truncation occur.  The following example was run with
cygwin version 1.3.17-1:

$ echo $CLASSPATH
/home/dnewton/dev/nextgen_src/build:/usr/software/lib/endorsed/xml-apis.jar:
/usr/software/lib/endorsed/xercesImpl.jar:/usr/software/lib/endorsed/xalan.j
ar:/usr/software/lib/bcel.jar:/usr/software/lib/bsf.jar:/usr/software/lib/js
.jar:/usr/software/lib/jakarta-oro-2.0.2.jar:/usr/software/lib/ojdbc14.jar:/
usr/software/lib/log4j-1.2.7.jar:/usr/software/lib/logkit.jar:/usr/software/
lib/maybeupload.jar:/usr/software/lib/junit.jar:/usr/software/lib/jdom.jar:/
usr/software/lib/ecs-1.4.1.jar:/usr/software/lib/avalonapi.jar:/usr/software
/lib/jakarta-regexp-1.2.jar:/usr/software/lib/jstyle.jar:/usr/software/lib/f
op-0_17_0.jar:/usr/software/lib/saxpath.jar:/usr/software/lib/jaxen-full.jar
:/usr/software/lib/antlr-all.jar:/usr/software/lib/servlet.jar:/usr/software
/lib/struts.jar:/usr/software/lib/getopt.jar:/usr/software/lib/gnu-regexp.ja
r:/usr/software/lib/jacorb.jar:/usr/software/lib/jboss-client.jar:/usr/softw
are/lib/jboss-common-client.jar:/usr/software/lib/jbossha-client.jar:/usr/so
ftware/lib/jboss-iiop-client.jar:/usr/software/lib/jboss-j2ee.jar:/usr/softw
are/lib/jboss-jaas.jar:/usr/software/lib/jbossjmx-ant.jar:/usr/software/lib/
jboss-jsr77-client.jar:/usr/software/lib/jbossmq-client.jar:/usr/software/li
b/jbossmqha.jar:/usr/software/lib/jboss-net-client.jar:/usr/software/lib/jbo
sssx-client.jar:/usr/software/lib/jboss-system-client.jar:/usr/software/lib/
jboss-transaction-client.jar:/usr/software/lib/jmx-connector-client-factory.
jar:/usr/software/lib/jmx-ejb-connector-client.jar:/usr/software/lib/jmx-rmi
-connector-client.jar:/usr/software/lib/jnp-client.jar:/usr/software/lib/con
current.jar:/usr/software/antExtensions/lib/checkstyle-2.4.jar

$ cygpath --path --unix $CLASSPATH
/home/dnewton/dev/nextgen_src/build:/usr/software/lib/endorsed/xml-apis.jar:
/usr/software/lib/endorsed/xercesImpl.jar:/usr/software/lib/endorsed/xalan.j
ar:/usr/software/lib/bcel.jar:/usr/software/lib/bsf.jar:/usr/software/lib/js
.jar:/usr/software/lib/jakarta-

This same behaviour with this test case exists through cygwin version
1.3.20-1.

I attempted to use an older version of the cygpath.exe (1.21) and the
problem did not occur.  (I didn't have an installation that included cygpath
1.21, so I took the cygpath.exe from a machine that had an older cygwin
installed, and replaced the cygpath.exe in my install with the old one.
Since cygpath.exe 1.21 worked running against the same cygwin1.dll, it would
seem that the bug is in the cygpath code.

(If you ask why I would convert unix to unix:   Our build environment always
uses unix format classpaths, but the current version of ant will always run
a "cygpath --path --unix $CLASSPATH" in its execution to insure it knows the
format when on a cygwin platform).

Has anyone else seen this problem, or is it known and due to be fixed?  I
looked at the cygpath.cc code in the in the online CVS history, and saw that
major changes occurred between cygpath 1.24 and 1.25, including removal of a
block of code that exits the function when no change is needed.  I'm not a
cygwin developer, but that looked at least a bit suspicious.

If you wouldn't mind, please copy any replies to dnewton@htc.net, as I am
not a subscriber.

Thanks in advance for any help.

--Doug Newton
dnewton@htc.net

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org