Regression in pathname between version 2.6.14 to 2.7.1

Greetings, and thanks for the note!

Actually, I thought this was more of a feature rather than a bug.
Pathname namestrings of the form "...//..." are inherently ambiguous
(e.g. ...//.. means ..././... in Linux et.al., but means / in emacs) and
are almost always the result of a lazy concatenation of paths, typically
avoiding merge-pathnames which should always give the right answer:

>(merge-pathnames  "../bar/baz" "etc/foo/")

>#P"etc/foo/../bar/baz"

That said I have a patch now testing which collapses // to /.

Take care,

Raymond Toy writes:

> This came up on the Maxima list. Consider
> 
> (let ((file (pathname "//tmp/.////test.txt")))
>   (with-open-file (stream file :direction :output :if-exists :supersede)
>     (values file (truename file)
>             (pathname stream))))
> 
> gcl 2.6.14 returns:
> 
> #p"/tmp/test.txt"
> #p"/tmp/test.txt"
> #p"/tmp/test.txt"
> 
> Losing the "/./" is unfortunate, but not really incorrect on Unix.
> 
> However, with gcl 2.7.1 we get:
> 
> Error:
> Fast links are on: do (si::use-fast-links nil) for debugging
> Signalled by PATHNAME.
> 
> Condition in PATHNAME [or a callee]: INTERNAL-SIMPLE-PARSE-ERROR: "//tmp/.////test.txt" is not a valid pathname on host NIL
> 
> Broken at PATHNAME.  Type :H for Help.
>     1  Return to top level. 
> >>
> 
> This version basically dislikes having consecutive slashes. On unix, this is equivalent to just one "/".
> 
> If you change the namestring to "/tmp/./test.txt", gcl 2.7.1 works and preserves the "/./".
> 
> It would be really nice to get this fixed before 2.7.2 is released.

-- 
Camm Maguire			     		    [email protected]
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah