PHP 4.0 Bug #7873 Updated: Dirname inconsistency

ID: 7873 User Update by: trifid@redigy.cz Status: Closed Bug Type: *Function Specific Description: Dirname inconsistency But PHP's dirname() used to work 'my' way allways, and I've seen a _lot_ of code that is broken by its current behaviour - a '//' on root is good for filesystem, but imagine a package which uses dirname($SCRIPT_NAME) to determine its web addres <a href=<? echo dirname($SCRIPT_NAME); ?>/foobar.html> produces in current version <a href=//foobar.html> which is obviously an invalid link. There is nothing wrong with 'pwd' as long as a filesystem understands something like '//'... but a web browser don't, and that's why I thought the original dirname() behaviour was intentional and very good. Previous Comments: --------------------------------------------------------------------------- [2000-11-19 09:06:33] stas@php.net This is the same way as "pwd" function behaves, so I guess your loginc od always adding / is not correct. Or you have to live with // on the root path. This is because root path is different from other pathes - / is actually its name, while on other pathes / is just a delimiter. Your patch makes root path to be "", which is obviously wrong. --------------------------------------------------------------------------- [2000-11-18 11:39:36] trifid@redigy.cz The last change in ext/standard/string.c brought very bad inconsistency into dirname behaviour: echo dirname("/foo/bar/")."/foobar"; => /foo/foobar echo dirname("/foo/")."/foobar"; => //foobar the function should everytime return a path with or without a slash at the end, but always the same. I created a very simple patch that will stop returning a slash at the end in any case: --- string.c.orig Sat Nov 18 17:00:28 2000 +++ string.c Sat Nov 18 17:04:53 2000 @@ -714,8 +714,7 @@ } if (end < path) { /* The path only contained slashes */ - path[0] = DEFAULT_SLASH; - path[1] = '