RE: [PHP-DEV] Directory separators on Windows

Hi, > -----Original Message----- > From: Rasmus Schultz [mailto:rasmus@mindplay.dk] > Sent: Saturday, April 1, 2017 11:13 AM > To: Pierre Joye <pierre.php@gmail.com> > Cc: Kris Craig <kris.craig@gmail.com>; Sara Golemon <pollita@php.net>; PHP > internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] Directory separators on Windows > > > Also ucfirst is useless (or any case operations) > > It's not useless, if you want a normalized path on Windows, it has to include a > drive-letter, and Windows FS isn't case-sensitive. > > > Right now realpath will fail if the path does not exist > > I know, that's one reason I don't use it. > > It kind of solves a different problem, e.g. resolves ".." and "." elements > in > paths... as a rule, I don't ever use relative paths, but it would certainly be nice to > have a realpath() that works for files that haven't been created yet. > > I don't think you can simply make realpath() also normalize the path, as this > would be a breaking change? > > I guess an improved realpath() could be used internally as part of a > normalize_path() function, but it's not enough on it's own, since the real path > will still have platform-specific directory-separators, so a > normalize_path() function would still be useful if realpath() gets improved. > > So to summarize, a normalize_path() function should: > > 1. Fully normalize to an absolute path with no platform-specific separators 2. > Have corrected case (for files/dirs that do exist.) 3. Have normalized (upper- > case) drive-letter on Windows > 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 > There's also network file-system paths on Windows with a different syntax to > consider? I don't know much about that... > > > On Fri, Mar 31, 2017 at 11:40 AM, Pierre Joye <pierre.php@gmail.com> wrote: > > > On Fri, Mar 31, 2017 at 3:32 PM, Rasmus Schultz <rasmus@mindplay.dk> > > wrote: > > > Well, this is the opposite of what I'm asking for, and does not > > > address > > the > > > case where paths have been persisted in a file or database and the > > > data gets accessed from different OS. > > > > > > I understand the reasons given for not changing this behavior in PHP > > > itself, so maybe we could have a standard function that normalizes > > > paths > > to > > > forward slashes? e.g. basically: > > > > > > /** > > > * Normalize a filesystem path. > > > * > > > * On windows systems, replaces backslashes with forward slashes > > > * and ensures drive-letter in upper-case. > > > * > > > * @param string $path > > > * > > > * @return string normalized path > > > */ > > > function normalize_path( $path ) { > > > $path = str_replace('\\', '/', $path); > > > > > > return $path{1} === ':' > > > ? ucfirst($path) > > > : $path; > > > } > > > > Also ucfirst is useless (or any case operations). realpath goes > > further down by solving ugly things like \\\\\\\ or ////// (code > > concatenating paths without checking trailing /\. > > > > > At least WordPress, Drupal and probably most major CMS and > > > frameworks > > have > > > this function or something equivalent. . > > > > Now I remember why they have to do that. > > > > realpath is not fully exposed in userland. virtual_file_ex should be > > used and provide the option to validate path or not. Right now > > realpath will fail if the path does not exist. I would suggest to > > expose this functionality/option and that will solve the need to > > implement such things in userland. > > > > ps: I discussed that long time with Dmitry and forgot to implement it, > > I take the blame for not having that in 7.x :) > > > > Cheers, > > Pierre > >