Faré wrote:
On Sun, Feb 2, 2014 at 7:38 PM, Robert P. Goldman rpgoldman@sift.info wrote:
I have been grappling with my inability to upgrade clisp, and find myself confused by the following events in my transcript:
[17]> (uiop/pathname:ensure-pathname "home:lisp;asdf;") #P"home:lisp;asdf;"
BEWARE! ENSURE-PATHNAME uses PARSE-UNIX-NAMESTRING, not PARSE-NAMESTRING. In this case, you want PARSE-NAMESTRING (possibly through PATHNAME).
(describe (uiop/pathname:ensure-pathname "home:lisp;asdf;"))
#P"home:lisp;asdf;" is a pathname, with the following components: NAME = "home:lisp;asdf;" VERSION = :NEWEST
Thanks. But isn't this a bug:
(uiop/pathname:ensure-pathname "home:lisp;asdf;" :namestring :lisp) #P"home:lisp;asdf;" [10]> (describe *)
#P"home:lisp;asdf;" is a pathname, with the following components: NAME = "home:lisp;asdf;"
Here I have explicitly told UIOP & clisp that the namestring is a LISP namestring, so it should see this as a valid logical-pathname, not garble the logical pathname into a PATHNAME's name field.
Here's the magic:
[12]> (describe (parse-namestring "lisp;asdf;" "home"))
#S(LOGICAL-PATHNAME :HOST "HOME" :DEVICE :UNSPECIFIC :DIRECTORY (:ABSOLUTE "LISP" "ASDF") :NAME NIL :TYPE NIL :VERSION NIL) is a portable pathname, with the following components: HOST = "HOME" DIRECTORY = (:ABSOLUTE "LISP" "ASDF")
This seems to have to do with an oddity (I suspect it's conforming, strictly speaking, but it's awkward at best, and impossible at worst) in clisp's interpretation of PARSE-NAMESTRING for logical pathnames.
I have absolutely no idea how to preserve usefulness of logical pathnames on clisp, since it looks like I would have to do a lot of horrible mess to try ripping colon-postfixed substrings off everything that might be a logical pathname, before feeding it to PARSE-NAMESTRING.
I suppose if ENSURE-PATHNAME is a bottleneck, I could try that there, wrapping some error-handling around a check...
cheers, r