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][2] 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.
[r13353]: http://trac.common-lisp.net/armedbear/changeset/13353 [2]: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/test/lisp/abcl/jar-...
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.