autoconf
[Top][All Lists]
Advanced

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

Re: path separator (was: target triplet)


From: Keith MARSHALL
Subject: Re: path separator (was: target triplet)
Date: Tue, 23 Jan 2007 17:16:43 +0000

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.
>
> STOP READING. Or better yet, read point (1) under MSYS. The above is 
> completely untrue disinformation until you read the later point.
>
> 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.

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).  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.

However, I will acknowledge that I am not a Cygwin expert; that's why I 
did
rather gloss over the Cygwin aspect, but perhaps I should have made it 
clearer
that the info may not be 100% reliable; the principal focus of my post was 
to
clarify the relationship between cmd.exe and MSYS sh.exe provisions for 
execing
native apps, and on those I can speak authoritatively.

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.

Regards,
Keith.




reply via email to

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