[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 10:34:21 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20061206 Thunderbird/ Mnenhy/

Keith MARSHALL wrote:
With Cygwin, you are running a POSIX emulation layer on top of the Win32 OS,
so your app gets all of the initialisation support you'd expect from a true
POSIX system.  There is no need for us to concern ourselves with the details
of how this happens; some very clever people have set it up for us, so that
it just works.  The aspects of it that are relevant to this discussion are:

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.

1) Cygwin's bash.exe assumes that the execed process will know how to use the
   Cygwin POSIX emulation layer to map Cygwin specific entity references to
   their native counterparts; if this isn't the case, as in the case of a Win32
   native app, then the onus falls squarely on the user to ensure that all
   references, and file system references, are specified in the proper *native*
   format; there is no assistance provided to perform the translation.

...and this is not true either. Cygwin "knows" when it is launching another Cygwin application vs. a native application. In fact, it has to, because there are certain semantics (either signal handling or something about return codes, I forget which) that require a 'wrapper process' when running a native application under Cygwin.

Everything said about MSYS seems to match *actual* Cygwin behavior, but if you want to be sure, ask on Cygwin's list.

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]