Re: expand-file-name, DOS/Windows, and directory separator

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Eric Abrahamsen [2022-02-15 09:59:53] wrote:
>> My reading of `expand-file-name' (I don't really speak C) is that, if we
>> run it over a file path produced by an external process on a Windows
>
> I'll let Eli confirm that this is indeed guaranteed behavior, but I just
> want to point out that the GNU convention (which we use) says these
> aren't "path"s but "file names".

Gotcha, I might have been trying to emphasize that it's the separators I
was interested in. Anyway, point taken.

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Date: Tue, 15 Feb 2022 09:59:53 -0800
>> 
>> My reading of `expand-file-name' (I don't really speak C) is that, if we
>> run it over a file path produced by an external process on a Windows
>> machine -- meaning path strings where the directory separator might be a
>> backward slash -- it will normalize that separator to a unix-style
>> forward slash. It looks like fileio.c:1247 calls dostounix_filename, and
>> I'm assuming that's what that does.
>> 
>> Is that a correct assumption?
>
> Yes.
>
>> Can I rely on that behavior?
>
> I'd rather you didn't.  Why do you need such an assumption?  Emacs on
> Windows can cope with file names that use any style of slashes.

This is code dealing with search results in Gnus, and the absolute file
names need to be broken up so we can work on their segments. Right now
that's done with regexps, which is ugly and fragile, and I'm just
looking for the confidence that:

(file-name-split (expand-file-name <file> "/"))

Is going to return exactly the segments, no more no less, regardless of
the system or separator type or whether there are multiple separators in
a row, etc etc. No leftover slashes, no empty strings, all that.

(Okay empty strings are fine, I guess `file-name-split' always returns
one for absolute file names.)