[armedbear-devel] TIcket #151 addressed (was Re: Spaces in pathnames (jar:file:/x/y/z/a space/...))
evenson at panix.com
Tue Jun 21 10:27:15 UTC 2011
On 6/6/11 22:46 , Theam Yong Chew wrote:
> Hope this is a good starting point? I believe this can later be folded
> into the unit tests?
With [r13353](), I believe that I finally have addressed your concerns.
I merged what I interpreted to be the meaning of your tests in
[abcl/test/lisp/jar-pathnames.lisp] avoiding the use of Alexandria to
not have dependencies in our test suite. You may want to verify again
with your "local conditions" (i.e. I haven't tested under windows") that
ticket #151 is truly fixed for you.
The rules adopted for URI encoding are
1. All pathname components are represented "as is" without escaping.
2. Namestrings are suitably escaped if the Pathname is a URL-PATHNAME
or a JAR-PATHNAME.
3. Namestrings should all "round-trip":
(when (typep p 'pathname)
(equal (namestring p)
(namestring (pathname p))))
The basics are that you should always encode #\Space as "%20" when you
use any of the "jar:", "jar:file:", "file:", or anything starting with a
URL schema as a namestring to construct a pathname.
The functions EXT:URI-ENCODE and EXT:URI-DECODE give the user a chance
to manipulate strings independently of the PATHNAME constrictors.
Strictly speaking these functions are not really RFC compliant routines
because what is escaped and what isn't is dependent on what section of
the URI one is dealing with, but they "seem to do the right thing" for
the basic URI schemas that I have tested. Someday this should be done
differently (unsure of how).
Hopefully this establishes a reasonable behavior for users wrt.
whitespace in pathnames. If this is not the case, please let us know.
"A screaming comes across the sky. It has happened before, but there
is nothing to compare to it now."
More information about the armedbear-devel