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
Date: Wed, 8 May 2002 10:30:34 +0200
From: Pavel Tsekov <ptsekov AT syntrex DOT com>
Reply-To: Pavel Tsekov <ptsekov AT syntrex DOT com>
Organization: Syntrex, Inc.
X-Priority: 3 (Normal)
Message-ID: <1035742317.20020508103034@syntrex.com>
To: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
CC: cygwin-apps AT cygwin DOT com
Subject: Re[2]: URL paths in setup.exe
In-Reply-To: <FC169E059D1A0442A04C40F86D9BA7600C6000@itdomain003.itdomain.net.au>
References: <FC169E059D1A0442A04C40F86D9BA7600C6000 AT itdomain003 DOT itdomain DOT net DOT au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello Robert,

Tuesday, May 07, 2002, 12:45:33 PM, you wrote:

RC> I'd like to formalise what file:// and cygfile:// schemes mean.

RC> file:// is a native filesystem URL handler - whatever the OS may be.
RC> cygfile:// is a handler that only makes sense on mingw platforms, and
RC> access's the cygwin mount table.

RC> This means that:
RC> file:///foo/bar.txt is /foo/bar.txt on posix, and Current
RC> drive:\foo\bar.txt on mingw.

I dont understand what you're saying here ? Please explain a little
bit more.

The URLParsers parses URLs, obviously, so it will parse anything in the
for <schema>://<authority>/path. Still currently it wont parse
if authority starts whith underscore - should I chage this ?

RC> As for file:// + d: + \foo\bar.txt, can we normalise that as 
RC> file://d|/foo/bar.txt - that is what MS do, and will be less confusing
RC> for users of the codebase (IMO).

I understand this. The URLParser class will also parse it without a
problem. The URLParsers has a convinient method called GetAbsPath
which will return the absolute path for a given schema making some
assumptions based on the schema i.e. if it the schema is file it will
return the path like that <authority>:\<path>..

1) I can remove this method - each io_stream class will have its own
means to get the path from the URL.

2) I can tweak the GetAbsPath so it assumes different from what it
assumes now.