[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: path separator (was: target triplet)

From: Matthew Woehlke
Subject: Re: path separator (was: target triplet)
Date: Tue, 23 Jan 2007 12:11:53 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20061206 Thunderbird/ Mnenhy/

Keith MARSHALL wrote:
Matthew Woehlke wrote:
1) The environment that is passed to your app is again a *verbatim* copy of
   that which was defined in the bash shell.

2) When you access command line arguments in argv, they are again *verbatim*
   copies of what you typed on the command line.

So, what's the difference from the cmd.exe case?  The *significant* difference
is that when your app refers to any file system entity, the reference no longer
needs to be specified in native Win32 format; it can just as well be in Cygwin's
POSIX compatible format, and the emulation layer will take care of mapping it to
the proper file system entity, without you needing to even know or care how.

Also the part about copying the environment verbatim is, I am 99% sure, also untrue. IIRC (and you could check on Cygwin's list if needed), at least $PATH is assumed to be in POSIX format and is converted to Windows format when launching a native application.

...and I should clarify, *only* $PATH (and I think $PWD and/or one or two others, but nothing else) is translated. So your statement is actually correct except you forgot the exception. :-)

I forget exactly what "others" is/are, but it's something that basically /has/ to be translated, because both POSIX (Cygwin) and Windows need it to be meaningful values in their 'language'. I.e. if Cygwin doesn't break, assume all variables that will be used by a native Windows program (like, e.g. LIB, INCLUDE) should be given in DOS style.

I once believed this to be the case myself; when I suggested so, on the MinGW list, only to be contradicted by none other than Christopher Faylor himself, (and Chris is a Cygwin Project *leader*, so I assume he would know).

Yes, I would hope CGF would be right. :-)

He  made it clear that, when invoking a native app, Cygwin would do just
what Linux would do, i.e. exactly *nothing*, wrt transforming path names
to native  form. So, now *you* have confused me; who is right, you or
Chris, who I would  expect to know?  Or, maybe I've just failed to
understand the scope of Chris's  flat denial of my *suggestion* that
Cygwin might perform such transformations; maybe the transformation is
performed for the environment, but not for  command line arguments; it
certainly isn't as extensive as in the MSYS case, which was the real
point I was trying to get over.

I am pretty sure Cygwin translates particular environment variables, i.e. at least $PATH, but you are correct that it does not translate command-line arguments. In general no translation is performed, just $PATH and IIRC one or two environment variables are translated. This is of course safe because the variables in question are used both in the POSIX world and in Windows, and have well-defined meanings (unlike command arguments whose meaning is application-defined).

Your original statement seemed to indicate that *native* Windows applications would 'magically' understand Cygwin's POSIX-style paths, which is wrong, but you clarified this later when talking about MSYS. Maybe that is a mis-reading of intention on my part, but the point was to clarify for anyone misreading in the same way. :-)

I don't know what MSYS does, so I can't speak to that.

Sorry for any inaccuracies in the minimal reference to Cygwin; my intention was to point out that MSYS goes to greater lengths to
co-operate with native applications.

That's OK, hopefully we've muddied the issue enough now that readers will either figure out the correct information (assuming one of us finally got it right!), or at least figure out that they need to make sure we know what we are talking about before relying upon it as The Gospel Truth. :-)

Don't read this. What did I just tell you? Why are you still reading?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]