Date: Wed, 24 Aug 2022 18:03:35 -0400
Cc: emacs-devel@gnu.org
From: Ken Brown <kbrown@cornell.edu>
Ugh, it means the test data needs to be split three-way: one for
MS-Windows/MS-DOS, another for Cygwin, and one more for the rest.
Because Cygwin is like Posix systems, but it does want to support
UNCs.
It's not just the test data that's wrong on Cygwin, but parse-colon-path is
wrong: It always collapses multiple leading slashes to two.
That's what substitute-in-file-name does as well (in the Cygwin and
MS-Windows/MS-DOS builds), and the change I made was meant to restore
backward compatibility with what parse-colon-path did as result of
using substitute-in-file-name.
Posix says that multiple leading slashes are equivalent to one slash *except* in
the case of exactly two leading slashes. In that case, the interpretation is
implementation-dependent.
This is not about Posix, this is about the Emacs-specific feature of
handling multiple consecutive slashes. In particular, in Emacs,
"/foo//bar" yields "/bar", not "/foo/bar" per Posix.
Cygwin follows Posix and chooses to interpret precisely two leading slashes as
referring to a UNC path. In particular, 3 or more slashes should be collapsed
to 1 slash, as on other Posix systems, while exactly 2 leading slashes should be
left alone.
I'm not against changing the behavior of substitute-in-file-name and
parse-colon-path in this regard, but it would be a separate change,
and of a long-standing behavior. This particular change just restored
what parse-colon-path did back when it used substitute-in-file-name.