Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98720
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 74.125.83.54 cause and error)
MIME-Version: 1.0
In-Reply-To: <187eb0be-90b9-f7cd-b8bd-888915429796@fleshgrinder.com>
References: <CADqTB_irwt+Q74KJp-0mBnc6L4S+XoBoKqtN7DwK=oR4Dkk-CA@mail.gmail.com>
 <CAESVnVqFcYr4tYYwUe3m3tepCZAkbbvZfrKPzk_xWUG3Jr+ezw@mail.gmail.com>
 <CAKOpQSydVTHo1zUdafNrFNc+ciQ1LBWu7OM+Ts8GEsztT32K7Q@mail.gmail.com>
 <CADqTB_i0YOfBibA+vj1RCCEOJjVLojy1f4SHYngGZE5MPjzqsQ@mail.gmail.com>
 <CAEZPtU7W8r8AsZQf-BZ+RL32pofQ-HMnJyV5YA3uz+ewG8rWVw@mail.gmail.com>
 <CADqTB_g4+q02FciVAoX+4O6uqsv+8EKrQhf8-HsZjCt-mZML-A@mail.gmail.com>
 <HE1PR02MB1052F074FE128646AF121348BA360@HE1PR02MB1052.eurprd02.prod.outlook.com>
 <187eb0be-90b9-f7cd-b8bd-888915429796@fleshgrinder.com>
Date: Sat, 1 Apr 2017 18:03:10 +0200
Message-ID: <CADqTB_jzptHP52kB5W8+d+1g-JsHCZJp3Cd=J_OG2Bi4TN5iwQ@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Cc: Anatol Belski <weltling@outlook.de>
Content-Type: multipart/alternative; boundary=94eb2c124e041890e2054c1d10fb
Subject: Re: [PHP-DEV] Directory separators on Windows
From: rasmus@mindplay.dk (Rasmus Schultz)

--94eb2c124e041890e2054c1d10fb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

10 thumbs up ;-)

But this really demonstrates how badly we need this function - I bet any
number of those points may or may not be covered by any number of
implementations in the wild.

It would be so nice to have this done "right", once and for all.


On Sat, Apr 1, 2017 at 2:42 PM, Fleshgrinder <php@fleshgrinder.com> wrote:

> On 4/1/2017 2:01 PM, Anatol Belski wrote:
> > 1. optionally - yes, otherwise it should do platform default
> > 2. no, this kind of operation is a pure parsing, no I/O related checks
> needed
> > 3. irrelevant, but can be defined
> >
> > Other points yet I'd care about
> > - result should be correct for target platform disregarding actual
> platform, fe target Linux path Windows, or Windows path on Mac, etc.
> > - validation, particularly for reserved words and chars, also other
> platform aspects
> > - encodings have to be respected, or UTF-8 only, to define
> > - probably should be compatible with PHP stream wrapper namespaces
> >
> >
> > Thanks
> >
> > Anatol
> >
>
> 1. How do you envision that? If the path is `/a/b/../c` where only `/a`
> exists right now? It's unresolvable, assuming that `../` points to `/a`
> is wrong if `b/` is a symbolic link that points to `/x/y`.
>
> 2. Here I agree, casing cannot be decided without hitting the
> filesystem. Some are case-sensitive, some insensitive, and others
> configurable.
>
> 3. Does not matter for Windows itself, it is case-insensitive.
>
> (I continue the numbering for the points you raised.)
>
> 4. How would we go about normalizing a Windows path to POSIX? `C:\a` is
> not necessarily the same as `/a`, or should it produce `C:/a`?
>
> 5. =F0=9F=91=8D
>
> 6. I vote for UTF-8 only. We already have locale dependent filesystem
> functions, which also makes them kind of weird to use, especially in
> libraries. Another very important aspect to take care of this point is
> normalization forms. Filesystems generally store stuff as is, that means
> that we can create to files with the same name, at least by the looks of
> it, which are actually different ones. Think of `=C3=A4` which can also b=
e
> `a=CC=88`. It is generally most advisable to stick to NFC, because that i=
s
> also how users usually produce those chars.
>
> 7. =F0=9F=91=8D just forward I'd say.
>
> 8. Collapse multiple separators (e.g. `a//b` ~> `a/b`).
>
> 9. Resolve self-references, unless they are leading (e.g. `a/./b` ~>
> `a/b` but `./a/b` stays `./a/b`).
>
> 10. Trim separators from the end (e.g. `a/` ~> `a`).
>
> --
> Richard "Fleshgrinder" Fussenegger
>

--94eb2c124e041890e2054c1d10fb--