Subject: bug#57102: 29.0.50; Peculiar file-name-split edge case

From: Philip Kaludercic <[email-masked]>
Date: Fri, 12 Aug 2022 15:56:02 +0000

Lars Ingebrigtsen <[email-masked]> writes:

> Philip Kaludercic <[email-masked]> writes:
>
>> I am not sure if this is intentional, but the new `file-name-split'
>> is a bit unintuitive in this edge-case:
>>
>>    (file-name-split "/")        → ("" "" "")
>>
>> while
>>
>>    (file-name-split "/a")       → ("" "a")
>>    (file-name-split "a/")       → ("a" "")
>>    (file-name-split "a/b")      → ("a" "b")
>
> The logic is that
>
> (equal (string-join (file-name-split foo) "/") foo)

How sensible is this in the first place?  Shouldn't it rather be
something like

(file-equal-p (apply #'file-name-concat (file-name-split filename)) filename)

[ which is currently likewise not given ]

Or to put it differently, who does the preceding empty string benefit if
we ignore the condition mentioned in the docstring?  Are there any
real-world use-cases?

> is supposed to be always true.  I see that's not the case in the "/"
> case, so that needs fixing.