This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: cygpath returns garbage if DOS/win2k input environment variable is too long?


OK. My turn to correct some misconceptions...

At 00:18 2002-09-26, Schaible, Jörg 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@PCGF590K:~> cygpath --unix "$CLASSPATH"
> ô??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 cannot use cygpath to convert Java class paths, unfortunately.

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


% echo "$CLASSPATH"

% cygpath -p -u "$CLASSPATH"

PATH-like variables in their native form are inscrutable to me, so I like 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 others). That file can be sourced on either Unix or Cygwin and provides no-op versions of the various conversions so that scripts that use them need not have OS-type discriminating code within them.

% classpath

% cdpath


If cygpath has to convert a path it uses an internal function of the Cygwin DLL that expects *real* paths and a Java class path typically have some jar files in it. I am not sure, whether this shoulkd be really fixed in the Cygwin DLL, since the called function uses internal path caching (at least what I saw from a *very* quick look) and the cache might not get filled with non-directory elements. This would require to implement the necessary functionality in cygpath. I already have it on my list, since I will change to Java development at some time, but the task is currently 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 about a JAR file? Nothing. Although it's equally irrelevant, JAR files are actually PKZIP files and can be processed by any program that understands that format (and will overlook their ".jar" suffix).

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

OTOH, you might not convert yout path to --unix anyway, since I doubt that 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. 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 functionality on top of the basic cygpath operations.


Randall Schulz
Mountain View, CA USA

Attachment: cygblend.bfd
Description: Binary data

Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]