RE: [PHP-DEV] Directory separators on Windows

> -----Original Message----- > From: Fleshgrinder [mailto:php@fleshgrinder.com] > Sent: Friday, March 31, 2017 8:32 PM > To: Anatol Belski <ab@php.net>; internals@lists.php.net; Rasmus Schultz > <rasmus@mindplay.dk> > Subject: Re: [PHP-DEV] Directory separators on Windows > > > $ php71 -a > php > echo dirname('C:\Folder/Resource\Resource'); > C:\Folder/Resource > > hmmm... just one example, this is what this whole discussion is about. > We are already super inconsistent. It seems as if this is not producing any issues > with PHP itself, as well as at least every extension I ever interacted with. > I can only link to this 😉 http://git.php.net/?p=php-src.git;a=commitdiff;h=ec78507bd46a05f77dbde3fa4091ab4c91e61cad the new implementation was consistent but had to be reverted in 7.1 partially, because of BC, even the use is inappropriate. Well, still normalization on Windows means having '\\' in terms of the platform API used, but just as a show case. The dirname function itself is based on the PHP implementation, not a platform API. But also, it would produce same path with different separators on different platform, if normalized. > Of course things are very different when it is about outputting paths and > forwarding them to other programs, which might be super shitty. (I look at you > protoc from Google, **grrr**.) However, that is something where > realpath/Ã2œO]jðżâ > ±¸Èpath_canonicalize/path_normalize would come into > play, and > something I would leave to the applications. Choosing the right situation where > the path requires those actions is impossible. > > We could also consistently convert paths to their native form. Hence, above > example would result in C:\Folder\Resource, or even > \\?\C:\Folder\Resource > (verbatim path, no further fiddling allowed). > > Both POSIX and Windows paths are well documented. However, it's not an easy > topic, that is for sure, and using slashes everywhere might be more destructive > than I anticipate. > You're right, they both are documented. What is not defined is the cross platform handling. There are some documents, yes, like RFC 3986, or RFC 1738 and RFC 8089 which are still in the proposed state. However there is none I knew that would care about crossplatform nuances in full extent. Particularly an RFC defining all the possible behaviors of the file:// scheme is what were needed, I guess. Thus my conclusion is to take the path of less resistance, as what is not defined is not necessary good but also is not necessary broken. Yeah, it is complex, and particularly in PHP historically grown, and just touching the water surface might already produce some high waves. The functions mentioned - of course, it were up to an application to decide what to use it in a particular situation, but not forcibly changing the core handling. Like in the snippet above, you would have currently to do dirname(realpath($path)), but that is also not crossplatform and won't work on a nonexistent file. So another function instead of realpath, like dirname(normalize_path($path, UNIXIFY_SLASH)) were in use. The implementation might be tricky in some parts, but in general doable. Regards Anatol