> -----Original Message----- > From: Fleshgrinder [mailto:p...@fleshgrinder.com] > Sent: Friday, March 31, 2017 6:29 PM > To: Anatol Belski <a...@php.net>; internals@lists.php.net; Rasmus Schultz > <ras...@mindplay.dk> > Subject: Re: [PHP-DEV] Directory separators on Windows > > On 3/31/2017 12:33 PM, Anatol Belski wrote: > > Regarding the path variants support - it's not quite that way. PHP > > streams abstract many things, for both simplicity and security. The > > current state has historically grown on these two factors. So far I > > can tell, the only what we don't support is a drive relative path and > > don't handle several irrelevant prefixes like device UID. > > > > While in general the info above is correct, things still stay platform > > dependent in many cases, while supported in PHP, too. Fe using "/" to > > access drive root ofc works, but might be surprisingly wrong if CWD is > > changed to another drive. Well, that's the platform nuance, with DOS > > one can have multiple roots. In other cases, like UNC, links or > > lately the long path prefix, the handling with PHP streams is > > completely transparent to the consuming script. > > > > A given case with a generated file is clearly the app responsibility. > > It is likely, that generated files moved between systems can cause > > arbitrary issues disregarding the actual platform. The mentioned case > > belongs to the same group, where I'd say there is no and cannot be a > > plausible general "fix". In addition to the EOL example by Rowan, > > another one of same could be escapeshell* functions. Taking in account > > also > > > > - backward compatibility - platform specific - compatibility with > > dependency libs, especially where it's impossible to integrate PHP > > streams - absence of the cross platform specifications, which is IMO > > the most of issue > > > > Even if we'd abstract ourselves from the initial app responsibility > > case - there are the portability nuances that are not simply to clear > > away by just renaming 'a' to 'b'. > > > > Regards > > > > Anatol > > > > Slow with the horses, we were only talking about backslash vs. slash, not > anything else. I only explained the various paths that are available on > Windows. > Well, there was slightly more in your msg, thus the response 😊
> We could use slashes everywhere, because every platform that is still in > existence supports it. That's about it, we cannot do much more, well, maybe > some normalization (e.g. self-references like `a/./b` to `a/b`, or removing > multiple slashes `a//b` to `a/b`). That's about it. Any other cross-platform > issues > are not solvable, and must be handled by applications. > Path normalization and forward slash everywhere are two different things. Having forward slash just because it is supported - nope, it's more an issue and should not be done. The path can be used everywhere - in the script itself, passed to external prog, written into a file, etc. The suggested "always forward slash" will cause endless conversion back and forth, in both user space and internally. Please check the 7.1 related parts, or even earlier versions, we already have to do some conversions because of these and similar matters, doing yet more while introducing breakages for existing software doesn't sound necessary. Any individual case in the given app is what matters. > A proper path abstraction would be awesome. Of course I would prefer an > object for it, but offering a `path_canonicalize` function as well for > starters is > good too. > Yep, a function to normalize path were doable. But again, the current implementations are platform dependent and use platform APIs. Such a function might need a re-implementations of those APIs, to produce results platform independently, that are valid on the target platform. Otherwise, more generalization doesn't look like having a base in absence of a consistent specs, at least I haven't seen any. Well, until someone takes it in the hand and files a draft to IETF 😊 Regards Anatol
