Re: master 95b1eacd47: Fix handling of UNCs in 'parse-colon-path

[Eli Zaretskii]

> 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.