Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Mail-Followup-To: cygwin-apps AT cygwin DOT com
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
Subject: RE: URL paths in setup.exe
Date: Tue, 7 May 2002 22:09:55 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Message-ID: <FC169E059D1A0442A04C40F86D9BA7600C6006@itdomain003.itdomain.net.au>
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
X-MS-Has-Attach: 
content-class: urn:content-classes:message
X-MS-TNEF-Correlator: 
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Earnie Boyd" <Cygwin-Apps AT cygwin DOT com>
Cc: "Pavel Tsekov" <ptsekov AT syntrex DOT com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id g47CCeB28668



> -----Original Message-----
> From: Earnie Boyd [mailto:earnie_boyd AT yahoo DOT com] 
> Sent: Tuesday, May 07, 2002 9:50 PM

> 
> cygfile:// makes no sense at all on my MinGW platforms.  What 
> mingw are you talking about? cygfile:// to me only makes 
> sense in Cygwin land.

In cygwin land, file:// can access posix paths via the standard C
library and C++ library calls. In MinGW land how do you access cygwin
posix paths? Answer: create your own library to read the cygwin mount
table (which setup has), and then wrap your C++ and C lib calls via that
(which is what cygfile:// does).
 
 >
> > This means that:
> > file:///foo/bar.txt is /foo/bar.txt on posix, and Current 
> > drive:\foo\bar.txt on mingw.
> 
> I don't see that working natively, so it doesn't work on my 
> MinGW, what mingw are you talking about?  I tried both 
> Netscape and IE, they both understand file://c:/temp/foo.txt, 
> though.  However, file:///temp/foo.txt wasn't found.

Ok, well sounds like MS only do absolute paths (which the spec
requires). 
 
> >
> > As for file:// + d: + \foo\bar.txt, can we normalise that as 
> > file://d|/foo/bar.txt - that is what MS do, and will be 
> less confusing 
> > for users of the codebase (IMO).
> 
> As I've already stated file://c:/foo/bar.txt also works.

Sure. Try file://c|/foo/bar.txt. You'll find that that works too - and
that is conformant URI syntax, whereas file://c:/foo/bar.txt is not.

Rob