Hi, My first instinct tells me, that it was closed by mistake, as from the first comment it could seem as the reported problem only happens if the path given to glob is outside of open_basedir. As the reported explained in his second comment, it is not the case, but glob returns different result for nonexistent path/pattern depending whether the open_basedir is set or not. I think that it is a bug, and I reopened the ticket. Maybe it would be a good idea to create a test case, and if it turns out to be the expected behavior, we can still add the testcase as an XFAIL.
On Sun, Oct 9, 2011 at 5:40 PM, Harald Lapp <harald.l...@gmail.com> wrote: > hi, > > could someone please enlighten me, why bug #47358 > http://bugs.php.net/bug.php?id=47358 was closed as "bogus"? the bug was > reported for 5.2.9 but applies to 5.3.x and 5.4.x as well. i can't see, why > glob should return 'false' if the search pattern does not match, even > though if the directory being searched in is valid compared to the > open_basedir settings: > > php -r "var_dump(glob('/tmp/*.php'));" > array(0) { > } > > vs. > > php -d "open_basedir=/tmp/" -r "var_dump(glob('/tmp/*.php'));" > bool(false) > > i fail to understand, why the second one is expected behaviour. > > i stumbled over this when playing with the fat free framework, which uses > quite a lot of glob statements in its autoloader, in a shared hosting > environment. > > thanks in advance, > > harald > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
