[Breaking] Make `basename` and `dirname` ignore a trailing path separator

[giordano]

Statement of the problem

Currently, basename and dirname have this documented, yet odd, behaviour:

julia> basename("/tmp/bar")
"bar"

julia> basename("/tmp/bar/")
""

julia> dirname("/tmp/bar")
"/tmp"

julia> dirname("/tmp/bar/")
"/tmp/bar"

What these functions do when there is a trailing path separator doesn't make any sense. For example, the Single Unix Specification, §3.170 doesn't allow empty files names, which are defined as follow:

A sequence of bytes consisting of 1 to {NAME_MAX} bytes used to name a file. The bytes composing the name shall not contain the <NUL> or <slash> characters.

Additionally, this doesn't match what the Unix utilities with the same names do:

% basename /tmp/bar
bar
% basename /tmp/bar/
bar
% dirname /tmp/bar 
/tmp
% dirname /tmp/bar/
/tmp

I was told that this behaviour was borrowed from Python's os.path.basename and os.path.dirname, but this doesn't change the fact it's meaningless.

This also makes it harder than necessary to automatically handle paths received from other functions, which may or may not have a trailing path separator, so if you are aware of basename and dirname oddness you have to do checks like

julia/base/file.jl

Line 235 in 85f4db2

isdirpath(path) && (path = dirname(path))

and a similar one is used in BinaryBuilder as well.

Solution

My suggestion is to make basename and dirname ignore trailing path separators.

This was discussed already in #33000 and resolved by explicitly documenting the current behaviour in #37580. Here I'd like to ask to consider making the breaking change for Julia v2.0, basically what #33021 tried to do. I'd argue that no one in their sane mind should rely on basename reporting an empty string: if they want to know whether a path ends with a path separator, that's the job of isdirpath. Therefore, my expectation is that this change will cause very little breakage in practice.

[elextr]

The "insane" behaviour you mention allows a path to be a directory and have it returned by dirname() without losing its last segment. The odd Unix behaviour does not allow that.

If we are talking breaking, my suggestion would be that basename() S/B renamed filenamepart() and dirname() S/B renamed dirpathpart() (or similar names) and then the current behaviour matches correctly the name and is totally useful for manipulating strings which contain file paths.

Then if anybody still wants the odd (but standardised) Unix behaviour the names dirname() and basename() are available for that use.

[giordano]

The "insane" behaviour you mention allows a path to be a directory and have it returned by dirname() without losing its last segment. The odd Unix behaviour does not allow that.

Are you referring to

julia> dirname("/tmp/bar/")
"/tmp/bar"

?

[elextr]

Yes, compared to Unix:

$ dirname /tmp/bar/
/tmp

PS I quoted "insane" to imply that I do not agree with the OP on that assessment, sorry if that confused anyone.

[giordano]

Well, I specifically don't like that behaviour, and I provided examples where you need extra checks to avoid dirname from giving the wrong result. When you get a path programmatically you can't control whether there is a trailing separator or not, and its presence affecting the result of dirname/basename is a complication.

[elextr]

So how do I pass a directory path as a string? The current behaviour allows indicating that to dirname() so it returns the whole thing.

Basically there are two behaviours that have differing use-cases, so given the choice, why not have both as I suggested, why cut off other peoples behaviours just because you don't want it?

[giordano]

I'm not opposed to having a different function which does something else. I'm still missing the use case (honestly I don't understand what you mean by "pass a directory as a string"), but that's not my concern, I'll probably not use it and that's it. I'd just like dirname/basename to follow the standard and consistent behaviour.

[elextr]

Good we agree, and I hope others do to, just please don't call behaviour for use-cases you don't know or understand "odd" "not sane" etc.

[tecosaur]

If we're going to think about this as a "Julia 2.0" change, I can't help but mention actually having a path type to work around a large class of "file paths are just strings" issues.