[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.
- target triplet, (continued)
- target triplet, Bob Rossi, 2007/01/21
- Re: target triplet, Ralf Wildenhues, 2007/01/21
- Re: target triplet, Bob Rossi, 2007/01/21
- Re: target triplet, Brian Dessent, 2007/01/21
- Re: target triplet, Ralf Wildenhues, 2007/01/21
- Re: target triplet, Keith MARSHALL, 2007/01/22
- path separator (was: target triplet), Ralf Wildenhues, 2007/01/22
- Re: path separator (was: target triplet), Bob Rossi, 2007/01/22
- Re: path separator (was: target triplet), Keith MARSHALL, 2007/01/23
- Re: path separator (was: target triplet), Matthew Woehlke, 2007/01/23
- Re: path separator (was: target triplet),
Keith MARSHALL <=
- Re: path separator (was: target triplet), Matthew Woehlke, 2007/01/23
- Re: path separator (was: target triplet), Brian Dessent, 2007/01/23
- Re: path separator (was: target triplet), Matthew Woehlke, 2007/01/23
- Re: path separator (was: target triplet), Brian Dessent, 2007/01/23
- Re: path separator, Paul Eggert, 2007/01/22
- Re: path separator, Ralf Wildenhues, 2007/01/23
- Re: path separator, Bob Rossi, 2007/01/23
- Re: path separator, Brian Dessent, 2007/01/23
- Re: path separator, Keith MARSHALL, 2007/01/24
- Re: path separator, Matthew Woehlke, 2007/01/24