GNU bug report logs -
#57102
29.0.50; Peculiar file-name-split edge case
Previous Next
Full log
View this message in rfc822 format
Eli Zaretskii <eliz <at> gnu.org> writes:
>> (file-name-split "/a/b")
>> => '("a" "b")
>
> This should return '("/" "a" "b"), or '("/a" "b") I think.
>
>> (file-name-split "//a////b////")
>> => '("a" "b")
>
> And this should return '("/" "a" "b" "/"), or '("/a" "b/").
>
>> I'm not sure what
>>
>> (file-name-split "c:/a/b")
>>
>> on Windows should return in that case, though.
>
> If you agree with the above, then '("c:/" "a" "b").
>
> If you don't care about the root directory, then '("a" "b")
> (a.k.a. "leave the interpretation to the caller").
I'm not at all sure, and perhaps we should have two different functions
here for the two different use cases that I think this function has.
The use cases, as I see it, are
1) "I just want to know which bits are in the path". This is used by
dabbrev, which wants to add "a" and "b" here to the abbrevs. In that
case, "c:/" is not what it wants.
2) "I need to perform some operation on each segment and then put the
file name back together again". This is what browse-url does -- it
wants to %-encode each segment, but not the "/"s, so it wants to
preserve the absolute/relative distinction. (But it needs to know that
the "c:/" part is not something to be encoded anyway.) In that case, I
think we want '("/" "a" "b") and '("c:/" "a" "b").
So perhaps file-name-split should keep the current semantics (but the
bugs identified should be fixed) for 2), but we could add a new function
(or optional parameter) for 1) which would leave "/"/"c:/" off.
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.