Documentation doesn't have the power to make something "not a bug". It shows that the behavior was not unintentional. But with such "powerful" justifications, can one ever hope to get the bug fixed?

But remove the trailing slash from the resulting string, because it doesn't look good,

The only "look" about it is that it makes it look like a Unix directory path, not a non-directory path. Though, I've run into enough things that just ignore trailing slashes that I've learned to append "/." (not just "/") to my directories when it really matters.

isn't necessary,

rsync, for one, disagrees. Specifying the intent that a directory is meant is often important and only "not necessary" if "in a perfect world". "mv foo bar/" is only the same as "mv foo bar" if you are 100% sure that bar already exists and is a directory.

and confuses OS/2.

Rather vague, there. That sounds like it might be a reason to strip the final '/' when on OS/2. So it might be a reason to impact the behavior of File::Spec::OS2. It is almost silly to mention that in File::Spec::Unix documentation (yes, they are two separate modules).

But I suspect the first justification is the real one and will actually end up being a powerful block against getting this improved. So more literal '/'s for all.

rsync, for one, disagrees

rsync man

this ok:

A trailing slash on the source changes this behavior to avoid creating an additional directory level at the destination. You can think of a trailing / on a source as meaning “copy the contents of this directory” as opposed to “copy the directory by name”

But here we see that leading '/' sometimes does not mean root

if the pattern starts with a / then it is matched against the start of the filename, otherwise it is matched against the end of the filename.

Thus “/foo” would match a file called “foo” at the transfer-root (see above for how this is different from the filesystem-root).

I think filename is filename. It points to file. When you passing arguments to command line programs - it's different thing - sometimes you need special syntax, depending on what you want to do

"mv foo bar/" is only the same as "mv foo bar" if you are 100% sure that bar already exists and is a directory.

yep, but there are problems when it's symlink to a directory example

Also basename

In the usual case, dirname() returns the string up to, but not including, the final '/'

Thank you vsespb and tye for your thoughts.

I agree with tye that the arguments for stripping the trailing slash as stated in the catdir documentation are weak. But, changing that method would certainly break a lot of existing code, which is why I was thinking of a new method to do this.

While I'm beginning to think both of you are right (just go with "/" as the directory separator for the various reasons you name), it still bugs me a little. Maybe this will demonstrate better:

use Path::Class;
# maybe $DIR is read from a configuration file or passed in from anoth
+er tool
my $d = dir($DIR);
$d = $d->parent->subdir("bar"); # one "right" way to do path manipulat
+ion
my $p = $d=~/\/$/ ? "$d" : "$d/";
[download]

Unless you're 100% sure that this system's path separator is "/", doesn't that last line feel like a bad practice? I'm still feeling some cognitive dissonance about this :-)

Maybe this is a solution? Here, we know that the separator will be a slash and that catdir's result won't have a trailing one.

require File::Spec::Unix;
my $x = File::Spec::Unix->catdir('foo','bar').'/';
[download]