Re: path separator (was: target triplet)

[Matthew Woehlke]

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?