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