delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2002/09/26/11:00:58

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-Id: <5.1.0.14.2.20020926073944.02041bc8@pop3.cris.com>
X-Sender: rrschulz AT pop3 DOT cris DOT com
Date: Thu, 26 Sep 2002 08:01:01 -0700
To: cygwin AT cygwin DOT com
From: Randall R Schulz <rrschulz AT cris DOT com>
Subject: RE: cygpath returns garbage if DOS/win2k input environment
variable is too long?
In-Reply-To: <C62850957C88154CB1C6CE03DE335E8B397CF1@mailstgeorgen.gft.c
om>
Mime-Version: 1.0

--=====================_209265265==_
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable

J=F6rg,

OK. My turn to correct some misconceptions...


At 00:18 2002-09-26, Schaible, J=F6rg wrote:
>Hi Ralf,
>
> > 1) In my win2k, I set (a long) Java CLASSPATH
> > 2) under cygwin I want to convert it (in my .tcshrc) an it
> > fails. If I do it
> > on the command line, it looks like the following:
> > rhauser AT PCGF590K:~> cygpath --unix "$CLASSPATH"
> > =F4??a?
>[...]
> >
> > My questions:
> > 1) is there a way to see an error-message from cygpath (a log
> > file or some
> > way to see stderr if there is any of that)?
>
>first of all: Even if cygpath would not indicate some buffer overflow, you=
=20
>cannot use cygpath to convert Java class paths, unfortunately.


Completely incorrect. I use "cygpath" to convert CLASSPATHs all the time=20
and it works just fine. Syntactically, they're just like PATH (on either=20
side of the Unix / Windows divide) and cygpath doesn't care what they're=20
used for, only what lexical / syntactic structure they have.

Witness:

% echo "$CLASSPATH"
c:/SD/tau/src;c:/SD/rrs/src;c:/JT/libs/cpj-1.3.0;c:/JT/libs/jgl3.1.0/src;c:/=
JT/libs/junit3.7;c:/JT/libs/junit3
.7/junit.jar;d:/j2sdkee1.3/lib/j2ee.jar

% cygpath -p -u "$CLASSPATH"
/cygdrive/c/SD/tau/src:/cygdrive/c/SD/rrs/src:/cygdrive/c/JT/libs/cpj-1.3.0:=
/cygdrive/c/JT/libs/jgl3.1.0/src:
cygdrive/c/JT/libs/junit3.7:/cygdrive/c/JT/libs/junit3.7/junit.jar:/cygdrive=
/d/j2sdkee1.3/lib/j2ee.jar


[
PATH-like variables in their native form are inscrutable to me, so I like=20
to use these:

path()              { echo "$PATH"              |tr ':' $'\n'; }
classpath()         { toUnixPATH "$CLASSPATH"   |tr ':' $'\n'; }
cdpath()            { echo "$CDPATH"            |tr ':' $'\n'; }


See the attached "cygblend.bfd" for the definition of toUnixPATH (and=20
others). That file can be sourced on either Unix or Cygwin and provides=20
no-op versions of the various conversions so that scripts that use them=20
need not have OS-type discriminating code within them.


% classpath
/cygdrive/c/SD/tau/src
/cygdrive/c/SD/rrs/src
/cygdrive/c/JT/libs/cpj-1.3.0
/cygdrive/c/JT/libs/jgl3.1.0/src
/cygdrive/c/JT/libs/junit3.7
/cygdrive/c/JT/libs/junit3.7/junit.jar
/cygdrive/d/j2sdkee1.3/lib/j2ee.jar

% cdpath

..
/c/SD/tau/src
/c/SD/rrs/src
/c/SD
/home/RSchulz
]


>If cygpath has to convert a path it uses an internal function of the=20
>Cygwin DLL that expects *real* paths and a Java class path typically have=
=20
>some jar files in it. I am not sure, whether this shoulkd be really fixed=
=20
>in the Cygwin DLL, since the called function uses internal path caching=20
>(at least what I saw from a *very* quick look) and the cache might not get=
=20
>filled with non-directory elements. This would require to implement the=20
>necessary functionality in cygpath. I already have it on my list, since I=
=20
>will change to Java development at some time, but the task is currently=20
>not scheduled. Anyone else may implenet it before *I* need it <g>.

There's nothing to fix and no shortcoming to alleviate. What's special=20
about a JAR file? Nothing. Although it's equally irrelevant, JAR files are=
=20
actually PKZIP files and can be processed by any program that understands=20
that format (and will overlook their ".jar" suffix).

The only thing cygpath cannot do (because no tool could do it, even in=20
principle, because of the many-to-one nature of the mapping to DOS names)=20
is get the "real" (long) Windows equivalent for a DOS name for which there=
=20
is no actual file present.


>OTOH, you might not convert yout path to --unix anyway, since I doubt that=
=20
>you have a JVM or Java compiler (except gjc) that understands cygwin paths.
>
> > 2) I did a work-around with assembling the path again in my .tcshrc.=20
> This is
> > not convenient. Any better ideas...?
>
>You could write a shell function that is generally able to do it.

Again, there's no need to do this unless you need to build extra=20
functionality on top of the basic cygpath operations.


>Regards,
>J=F6rg


Randall Schulz
Mountain View, CA USA

--=====================_209265265==_
Content-Type: application/octet-stream; name="cygblend.bfd"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="cygblend.bfd"

I0JBTkcgLS0gc291cmNlIHRoaXMgZmlsZQoKIyBEZWZpbmUgc2hlbGwgZnVuY3Rpb25zIHRoYXQg
dHJhbnNsYXRlIFdpbmRvd3MgZmlsZSBuYW1lcyBhbmQgcGF0aCB2YXJpYWJsZXMKIwl0byBhbmQg
ZnJvbSB0aGVpciBVbml4IC8gUE9TSVggKGFuZCBDeWd3aW4pIGVxdWl2YWxlbnRzCgoKaWYgWyAi
JE9TVFlQRSIgPSAiY3lnd2luIiBdOyB0aGVuCgoJdG9Mb2NOYW1lKCkgeyBjeWdwYXRoIC13ICIk
MSI7IH0KCXRvTG9jUEFUSCgpIHsKCQlpZiBbIC16ICIkMSIgXTsgdGhlbgoJCQlyZXR1cm4gMAoJ
CWVsc2UKCQkJY3lncGF0aCAtdyAtcCAiJDEiCgkJZmkKCX0KCiMJdG9DeWdOYW1lKCkgeyBjeWdw
YXRoIC11ICIkMSIgfHNlZCAtZSAnc3wvY3lnZHJpdmUvfC8vfGcnOyB9Cgl0b0N5Z05hbWUoKSB7
IGN5Z3BhdGggLXUgIiQxIjsgfQoJdG9DeWdQQVRIKCkgewoJCWlmIFsgLXogIiQxIiBdOyB0aGVu
CgkJCXJldHVybiAwCgkJZWxzZQoJCSMJY3lncGF0aCAtdSAtcCAiJDEiIHxzZWQgLWUgJ3N8L2N5
Z2RyaXZlL3wvL3xnJwoJCQljeWdwYXRoIC11IC1wICIkMSIKCQlmaQoJfQoKIwl0b1VuaXhOYW1l
KCkgeyBjeWdwYXRoIC11ICIkMSIgfHNlZCAtZSAnc3wvY3lnZHJpdmUvfC8vfGcnOyB9Cgl0b1Vu
aXhOYW1lKCkgeyBjeWdwYXRoIC11ICIkMSI7IH0KCXRvVW5peFBBVEgoKSB7CgkJaWYgWyAteiAi
JDEiIF07IHRoZW4KCQkJcmV0dXJuIDAKCQllbHNlCgkJIwljeWdwYXRoIC11IC1wICIkMSIgfHNl
ZCAtZSAnc3wvY3lnZHJpdmUvfC8vfGcnCgkJCWN5Z3BhdGggLXUgLXAgIiQxIgoJCWZpCgl9CgoJ
dG9XaW5OYW1lKCkgeyBjeWdwYXRoIC13ICIkMSI7IH0KCXRvV2luUEFUSCgpIHsgY3lncGF0aCAt
dyAtcCAiJDEiOyB9CgplbHNlCgoJdG9Mb2NOYW1lKCkgeyBlY2hvICIkMSI7IH0KCXRvTG9jUEFU
SCgpIHsgZWNobyAiJDEiOyB9CgoJdG9DeWdOYW1lKCkgeyBlY2hvICIkMSI7IH0KCXRvQ3lnUEFU
SCgpIHsgZWNobyAiJDEiOyB9CgoJdG9Vbml4TmFtZSgpIHsgZWNobyAiJDEiOyB9Cgl0b1VuaXhQ
QVRIKCkgeyBlY2hvICIkMSI7IH0KCgkjIFByZXN1bWFibHkgdGhpcyB2YXJpYW50IGlzIG5ldmVy
IG5lZWRlZC4uLgojCXRvV2luTmFtZSgpIHsgZWNobyAiJDEiOyB9CiMJdG9XaW5QQVRIKCkgeyBl
Y2hvICIkMSI7IH0KCmZpCg==

--=====================_209265265==_
Content-Type: text/plain; charset=us-ascii

--
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/
--=====================_209265265==_--

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019