I noticed that splittist reported on #abcl that abcl-0.23.0 has fails to
start if it is in a directory that contains #\Space characters.
The problem is related to my "fix" for loading Pathnames that contain
#\+ characters which reveals that we are too undecided with our encoding
of a JAR Pathname.
The problem arises by not rigorously treating Pathnames with "jar:" and
"file:" prefixes as having URLEncoded DIRECTORY, NAME, and TYPE
components, which seems to be how the java.net.URL classes treat them.
Although this seems innocent, when ABCL loads its FASLs it always using
this code so this deeply effects the system operation, although normally
no one actually constructs such URLs.
My proposed fix would be to treat all inputs to Pathname which construct
with "jar:" and "file:" schema as being URLEncoded. Likewise, we would
fix the namestring routines to provide such encoding on the "way out" to
string representations.
There would therefore be a difference between
(pathname-directory "file:/containing%20a%20space/")
==> (:ABSOLUTE "containing a space")
and
(pathname-directory #p"/containing%20a%20space/")
==> (:ABSOLUTE "containing%20a%20space")
There would be a bit of a surprise that
(pathname-directory "file:/cl+ssl!/foo.lisp")
==> (:absolute "cl ssl")
It will take some time to chase down all the code paths here, so please
comment if this solution is still ambiguous in some way that I haven't
anticipated, or if someone has different proposal.
--
"A screaming comes across the sky. It has happened before, but there
is nothing to compare to it now."