Weird File::Basename::basename

McA has asked for the wisdom of the Perl Monks concerning the following question:

Hi Monks,

just stumbled on the following behaviour of File::Basename::basename.

#!/usr/bin/perl
use 5.010;
use strict;
use warnings;

use File::Basename;
say "$File::Basename::VERSION\n";

my $filename = '';
say $filename, ' - basename($filename) -> ', basename($filename);
say $filename, ' - dirname($filename) -> ', dirname($filename);
[download]

The basename of an empty string is ./ which I really didn't expect. To cite the documentation:

dirname() and basename() emulate the behaviours, and quirks, of the shell and C functions of the same name. See each function's documentation for details.

But basename of empty string on bash is an empty string. The same for C library basename.

Is this a bug?

McA

Comment on Weird File::Basename::basename Select or Download Code

Replies are listed 'Best First'.
Re: Weird File::Basename::basename (yes, but) by Anonymous Monk on Mar 26, 2013 at 15:26 UTC
Is this a bug? Yes , I think so. See http://perl5.git.perl.org/perl.git/blob/HEAD:/lib/File/Basename.t, its a typical bug (if a boundary condition isn't tested, chances are it'll be broken) OTOH, on the scale of importance/severity, I would classify this bug as unimportant FWIW, you should perlbug it just the same :) functions should do what they claim to do -- and they might as well explicitly spell out what that is instead of merely referring to the manpages -- I'll bet if the pod actually spelled out the full behaviour, there would have been a test for it in the test suite :)	[reply]
Re^2: Weird File::Basename::basename (yes, but) by hdb (Monsignor) on Mar 26, 2013 at 15:43 UTC
On the importance of this bug: In a way "./" is the neutral element in pathes in the sense of adding it anywhere in the path does not change anything (except in the middle of a name obviously). One exception springs to mind: When executing a command it does make a difference whether to say `system("somecommand"); # or system("./somecommand");` [download] Whether or not this can happen due to the usage of `basename('')` in any practical example I am not sure.	[reply] [d/l] [select]
Re^3: Weird File::Basename::basename (yes, but) by Anonymous Monk on Mar 26, 2013 at 16:42 UTC
When executing a command it does make a difference whether to say "foo" or "./foo" not on cmd.exe, cwd is first place searched :) spec/basename are useful, but they're kinda low-level, I prefer abstractions like Path::Class and Badger::Filesystem and absolute paths, so file( ... )->absolute	[reply]
Re: Weird File::Basename::basename by RichardK (Parson) on Mar 26, 2013 at 16:11 UTC
I prefer to use File::Spec splitpath, as it seems more logical and does the right thing -- even if volume doesn't make any sense on a proper system ;)	[reply]
Re: Weird File::Basename::basename by McA (Priest) on Mar 27, 2013 at 04:29 UTC
Hi, UPDATE: I made a little test program in C to see the behaviour there. Interestingly the `basename('')` is `'.'`. So it seems we have now three different results: Shell: `basename '' => ''` File::Basename: `basename '' => './'` C basename: `basename '' => '.'` McA	[reply] [d/l] [select]