Question about bug #41262

Hi all,

just a question why this [1] is not a bug? Well, we know why PHP is doing
this, but IMHO that's not correct.

As of my understanding this function just split a given path in parts. The
given path parameter is complete independend from the local filesystem (or
os?). It can also be the path componente of an (ftp) URI.

So, why depends the return value in this one case on the local filesystem
and without any info in the documentation?

For example if I use the result of this function in a dynamic generated pdf
file for a documentation. It's also not possible to have a correct root for
an URI. I must not use the result for a following local file access. A ""
is definitely not the same as "/". ( var_dump('\' == '/'); ;-) )

BTW:
With dirname() you have the same behaviour.

Regards,
Carsten

[1] http://bugs.php.net/bug.php?id=41262

Stefan Priebsch schrieb:

I always use something str_replace('\', '/', $aFilename) before I work
with filenames, and normally have no cross-plattform issues with that. I
also do it after using realpath(), for example.

I know. It's really a pain. In many times you must correct the PHP behavior
in your PHP code :-/ (Or just use pcre for such tasks)

On my bsd box (only PHP 5.0x) it's also curious when I try to build
batchfiles for Windows. A "dirname('C:\Windows\foo')" returns "." ...
(Maybe it's correct if I upgrade PHP?)

I know this is not really to the point, but it might just help you work
around the problem.

It's not a current problem from me. Only a point which IMHO should be
corrected. But thanks anyway.

Regards,
Carsten