dirname("/perl/") == "/perl"
dirname("/perl/lib//") == "/perl/lib"
That's what I'd think, anyway. But the tests specificly contradict this
saying
dirname("/perl/lib//") == "/perl"
and specificly pointing out that 5.003_18 returned /perl/lib which was
"wrong".
According to the documentation the current behavior is both correct and
incorrect. The docs say dirname() "returns the directory portion of the
input file specification". So in that sense its wrong. But it also says
dirname() "conforms to the behavior of the Unix shell command dirname(1)"
Here's how the BSD manpage describes how it works:
The dirname utility deletes the filename portion, beginning with the last
slash `/' character to the end of string (after first stripping trailing
slashes), and writes the result to the standard output.
Note they refrain from saying that it actually returns the directory name!
It smells like a euphemism for "this function is weak and broken but we
retain the broken functionality for backwards compatibility purposes".
So does File::Basename follow the shell over this cliff or does dirname()
actually return the directory name? Do we slavishly remain compatible with
dirname(1) or correct its mistakes?
As I can probably count on one hand the number of people who are using
dirname() to mimic the exact behavior of dirname(1), as opposed to simply
expecting it to return the directory, I think we can safely fix this. I
can also probably count on one hand the number of people who are aware of
these caveats about dirname(1).
This also closes some discrepencies between dirname() and fileparse().
Currently...
(fileparse("/bar/"))[1] == "/bar/"
dirname("/bar/") == "/"
(fileparse("bar/"))[1] == "bar/"
dirname("bar/") == "."
They should be equivalent.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Don't try the paranormal until you know what's normal.
-- "Lords and Ladies" by Terry Prachett
