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. :-)
--
Matthew
Don't read this. What did I just tell you? Why are you still reading?
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
