GNU bug report logs - #57102
29.0.50; Peculiar file-name-split edge case

Previous Next

Package: emacs;

Reported by: Philip Kaludercic <philipk <at> posteo.net>

Date: Wed, 10 Aug 2022 08:26:02 UTC

Severity: normal

Found in version 29.0.50

Full log


View this message in rfc822 format

From: Philip Kaludercic <philipk <at> posteo.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 57102 <at> debbugs.gnu.org
Subject: bug#57102: 29.0.50; Peculiar file-name-split edge case
Date: Fri, 12 Aug 2022 15:56:02 +0000
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Philip Kaludercic <philipk <at> posteo.net> 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.




This bug report was last modified 2 years and 355 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.