Bug #72582 [Com]: RecursiveDirectoryIterator with UNIX_PATHS flag doesn't work

From: Date: Tue, 12 Jul 2016 15:18:00 +0000
Subject: Bug #72582 [Com]: RecursiveDirectoryIterator with UNIX_PATHS flag doesn't work
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-202243@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=72582&edit=1 ID: 72582 Comment by: rasmus at mindplay dot dk Reported by: rasmus at mindplay dot dk Summary: RecursiveDirectoryIterator with UNIX_PATHS flag doesn't work Status: Verified Type: Bug Package: SPL related Operating System: Windows PHP Version: 7.0.8 Block user comment: N Private report: N New Comment: > Of course, the mixed directory separators are usually not desired I think it's fair to say, they're never desired - you want either UNIX or Windows paths, there's no scenario (least of all printing to display) where having a mix isn't just "weird". > but still the > implementation would make some sense, as only the given $path will > contain Windows directory separators, but not the rest, cf. I don't think that makes sense. You'd have to update the documentation to explain that it only normalizes the sub-paths - but that would be completely pointless; if I have to normalize the base path myself, that means I have to normalize paths myself, which means I might as well just normalize all the paths myself. As is, this feature suggests I wouldn't need to, but that's not true. What possible use would anyone have for a partially normalized path? I don't see how this is not a bug. Previous Comments: ------------------------------------------------------------------------ [2016-07-12 11:54:27] cmb@php.net I can confirm this behavior. I'm not sure, whether this qualifies as implementation or a documentation bug, though. Of course, the mixed directory separators are usually not desired, but still the implementation would make some sense, as only the given $path will contain Windows directory separators, but not the rest, cf. <?php $files = new RecursiveIteratorIterator( new RecursiveDirectoryIterator( __DIR__, RecursiveDirectoryIterator::SKIP_DOTS | RecursiveDirectoryIterator::UNIX_PATHS ) ); foreach ($files as $file) { var_dump($file->getPathname()); // paths with mixed dir separators } > I often find myself wondering why backslashes are used in paths > on Windows at all? Consider exec(), for instance. ------------------------------------------------------------------------ [2016-07-12 08:20:47] rasmus at mindplay dot dk Description: ------------ The UNIX_PATHS flags, according to documentation, "Makes paths use Unix-style forward slash irrespective of system default". This is important e.g. for the purposes of comparing paths, but it doesn't seem to have any effect on Windows. The paths have backslashes regardless of setting this flag. I also tried setting the CURRENT_AS_PATHNAME flag, since I suspected this was due to the fact that iterators etc. likely *can't* impose this change on SplFileInfo instances in the first place? Even if they could, that would make the behavior of SplFileInfo::getPathname() somewhat unpredictable. I'm currently forced to do something like $path = strtr('\\', '/', $path) in every program that compares paths, to make sure it works on Windows, which is really messy. (I often find myself wondering why backslashes are used in paths on Windows at all? Since forward slashes work just fine. One usually cares more about paths being comparable, e.g. actually working and behaving predictably and consistently, than what it looks like when printed on screen...) Test script: --------------- <?php $files = new RecursiveDirectoryIterator( __DIR__, // (or somewhere specific) RecursiveDirectoryIterator::SKIP_DOTS | RecursiveDirectoryIterator::UNIX_PATHS ); foreach ($files as $file) { var_dump($file->getPathname()); // paths with backslashes :-( } Expected result: ---------------- UNIX-style forward slashes, per the description of the flag. Actual result: -------------- Mixed Windows/UNIX-style backslashes and forward slashes. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=72582&edit=1

« previous php.bugs (#202243) next »