On Thu, Jun 30, 2005 at 03:58:40AM -0700, Glenn Linderman wrote: > On approximately 6/30/2005 1:28 AM, came the following characters from > the keyboard of Michael G Schwern: > > dirname("/perl/") == "/perl" > > dirname("/perl/lib//") == "/perl/lib" > > not dirname("/perl/lib//") == "/perl/lib/" ?? > not dirname("/perl/lib//") == "/" ?? > > Now of course I don't know of any filesystems that actually allow null > directory names... some programs interpret /stuff//more/ as > /stuff/more/ and others interpret it as /more/ so there is some > ambiguity here.
Multiple slashes are simply reduced to a single slash. If a program is interpreting /stuff//more/ as /more its busted. I'd be interested in an example of one which exhibited that behavior and bonk the author on the head. Its not only wrong but it leads rapidly to security holes. my $path = "/foo/bar/$user_input"; If $user_input = '/etc/passwd' and multiple slashes are interpreted as the top level directory then I can now access any file on the filesystem. > On the other hand, what should/does > > dirname("/perl//lib") > > "/perl" or "/perl/" ??? /perl. File::Basename always strips the trailing slash. It would be nice if it left it on so one could continue to recognize that its a directory and not a file, but stripping the trailing slash seems to be The Thing To Do as its what File::Spec->canonpath does and I'm not worried about it at this time. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern ROCKS FALL! EVERYONE DIES! http://www.somethingpositive.net/sp05032002.shtml