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
