Opened 8 years ago
Last modified 7 years ago
#953 reopened defect
Can't load from logical pathname when *default-pathname-defaults* is logical
Reported by: | fare | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Compiler | Version: | trunk |
Keywords: | ITA | Cc: |
Description
touch /tmp/x.asd ccl (setf (logical-pathname-translations "FOO") '(("**;*.asd.*" #P"/tmp/**/*.asd.*"))) (let ((*default-pathname-defaults* #P"FOO:")) (ccl::FIND-LOAD-FILE #P"FOO:x.asd.newest")) ==> Error: Illegal logical namestring "/tmp/x.asd" > While executing: CCL::STRING-TO-PATHNAME, in process listener(1).
The file has to exist, and the *default-pathname-defaults* has to be logical.
Actually, if the argument is "/tmp/x.asd" instead of "foo:x.asd", there is a different error:
> Error: Illegal logical namestring "/tmp/**/*.asd.*"
This makes thing fail in ASDF when using logical pathnames (I suspect since asdf 2.017.6, that binds *default-pathname-defaults* around the loading of the .asd).
Change History (8)
comment:1 Changed 8 years ago by gb
comment:2 Changed 8 years ago by gb
(In [15330]) NATIVE-TO-PATHNAME: bind *DEFAULT-PATHNAME-DEFAULTS* to #P"", in case it's already bound to something questionable.
See ticket:953.
comment:3 Changed 7 years ago by gz
- Keywords ITA added
comment:4 Changed 7 years ago by fare
Note that your solution, which I've also been trying to use, of binding d-p-d to #p"" will fail miserably if #p"" was itself read while d-p-d was "logical".
I don't know if this can possibly happen during a normal (re)compilation of CCL (hopefully not), but it can definitely happen during a compilation of some of the software for which I've been using this workaround.
It is surprisingly hard to *portably* get a non-logical pathname at all. My current bet is basically on (make-pathname :host nil), though I was suggested (translate-logical-pathname (user-homedir-pathname)), which unhappily isn't as portably supported as it should.
Ticket 978 is possibly related.
comment:5 Changed 7 years ago by fare
That's ticket:978
comment:6 Changed 7 years ago by gz
- Resolution set to fixed
- Status changed from new to closed
(In [15744]) Don't merge with *default-pathname-defaults* in native-translated-namestring. Fixes ticket:953
comment:7 Changed 7 years ago by gz
- Resolution fixed deleted
- Status changed from closed to reopened
comment:8 Changed 7 years ago by gz
I got the wrong ticket number. [15744] has nothing to do with this here, sorry.
Simpler ways of provoking the same error include:
and
Of 5 implementations that I looked at (CCL, SBCL, CLISP, LispWorks?, and Allegro), all but CLISP erred on [b]; CCL and SBCL erred on [a] as well. In all cases when an implementation signals an error, the error message is essentially the same as what you observe (a physical namestring isn't a valid logical namestring.)
It might make some sense to bind *DEFAULT-PATHNAME-DEFAULTS* to a pathname consisting of only a logical host around some body of code if you know exactly what pathname operations that body of code performs. You don't know exactly what pathname operations LOAD (or the code that's loaded) will perform.
The particular error that you get comes from something like [a], and I suppose that the call to PATHNAME in that case could be surrounded by a binding of *DEFAULT-PATHNAME-DEFAULTS* to #P"" to defend against an inappropriate surrounding binding. I'm not sure that I see a CCL bug here though, and I suspect that you'll find that binding that variable as you do will have lots of unintended interactions with the implementation and/or the user-level code being loaded.