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
