Hi, > -----Original Message----- > From: Fleshgrinder [mailto:p...@fleshgrinder.com] > Sent: Thursday, March 30, 2017 8:05 PM > To: Rasmus Schultz <ras...@mindplay.dk>; PHP internals > <internals@lists.php.net> > Subject: Re: [PHP-DEV] Directory separators on Windows > > On 3/30/2017 3:25 PM, Rasmus Schultz wrote: > > Thoughts? > > > > Windows and paths is a complicated and lengthy story. > > TL;DR all versions of Windows are able to deal with slashes, and we could > easily > use slashes everywhere all the time. > > # History > The story why Windows is using the backslash might be of interest, read: > > http://blogs.msdn.com/b/larryosterman/archive/2005/06/24/432386.aspx > > This also explains that Windows IS supporting forward slashes since at least > the > 1990s. However, there are programs that have significant problems with it, but > usually those are old or otherwise shitty programs. > > There are various ways paths can be represented in Windows, the so called path > variants. There are 7 in total: > > 1. Root > 2. Disk > 3. UNC > 4. Device Namespace > 5. Verbatim Disk > 6. Verbatim UNC > 7. Verbatim Device Namespace > > ## Root > This works just line on Unix an can be either `\` or `/`. It always refers to > the root > directory of the current drive. > > ### Home > PowerShell also supports the home short-hand `~` like Unix systems, however, > `cmd.exe` does not. > > ## Disk > This is the one we all know. The drive letter comes first, followed by a > colon `:`, > and then continues with the actual path. > > `C:\Folder\Resource` > `C:/Folder/Resource` > > ## UNC > Is short for **Universal Naming Convention** or **Uniform Naming > Convention** allows one to refer to network paths or server shares. > > `\\ComputerName\SharedFolder\Resource` > `//ComputerName/SharedFolder/Resource` > > It also has an extended form for web resource: > > `\\CompuserName[@SSL][@Port]\SharedFolder\Resource` > > ## Device Namespace > This allows one to directly address special devices, or again the disks > themselves. > > `\\.\Device\Resource` > `//./Device/Resource` > > ## Verbatim * > The verbatim paths work exactly the same way as the respective normal > counterpart, the difference is that the slash to backslash conversion does NOT > happen auto-magically: > > `\\?\C:\Folder\Resource` > `\\?\Server\Share` > `\\?\UNC\Server\Share` > > https://en.wikipedia.org/wiki/Path_(computing) > > I highly recommend you to have a look at Rust's path implementation, as it > takes > care of all these things in a very intelligent manner. It is also capable of > dealing > with all variants of paths in Windows, unlike PHP which only supports a few: > > https://doc.rust-lang.org/std/path/index.html > 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
