# bug #47358 -- unexpected behaviour

- Thread: https://externals.io/message/55762
- Original archive: https://news-web.php.net/php.internals/55762
- Started by Harald Lapp on 2011-10-09T15:40:24+00:00
- Messages: 3
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #55762 — Harald Lapp — 2011-10-09T15:40:24+00:00

URL: https://externals.io/message/55762#55762

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

---

## #55764 — Ferenc Kovacs — 2011-10-09T16:04:49+00:00

URL: https://externals.io/message/55762#55764 · In reply to: #55762

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.


> 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
>
> --
> 
> 
>
>



-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

---

## #55766 — Pierre Joye — 2011-10-09T16:52:42+00:00

URL: https://externals.io/message/55762#55766 · In reply to: #55762

hi,

Thanks for the headup!

I added a comment and attached a patch (against 5.4) to fix this
problem, let me know how it works. I will apply to all branches later.


> 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
>
> --
> 
> 
>
>



-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org