[armedbear-devel] Spaces in pathnames (jar:file:/x/y/z/a space/...)

[Mark Evenson]

On Jun 6, 2011, at 22:46 , Theam Yong Chew wrote:

[…]

> Sorry for the slow reply, I've been thinking about a good way to go
> about this problem. test.lisp is my initial attempt at exposing all
> possible space-in-path possibilities (probably not complete yet). It's
> also not very systematic yet, but for now, I'm trying to find out
> both cases that work and cases that don't.
> 
> In the following, I'm trying to compare the differences between an
> older abcl and my single-line patched version. I'm sorry the test
> indices are not too informative, as this is just a rough first try,
> and I need to go to sleep soon (please double check test.lisp, I might
> have been sloppy too).

[…]

> Hope this is a good starting point? I believe this can later be folded
> into the unit tests?

Your tests certainly provide good starting point.  Some of the
failures I get end from running a slightly modified version of
'test.lisp' end in restarts that only allow me to abort the thread,
so I don't currently get a clean version to compare to your results.

I will try to incorporate these tests into the ABCL RT test suite
over the next few days, and then look at a strategy for dealing
with the problems.

My general plan for addressing the "when do I need escaping?" is
to use the hitherto non-obvious feature that ABCL actually has two
subtypes of PATHNAME, URL-PATHNAME and JAR-PATHNAME:

CL-USER> (type-of #p"foo/bar") PATHNAME CL-USER> (type-of
#p"http://foo/bar") URL-PATHNAME CL-USER> (type-of
#p"jar:http://foo/bar!/") JAR-PATHNAME

The rule should be that both URL-PATHNAME and JAR-PATHNAME would
have URI escaped components on creation.  I think we just need to
have the various escaping/unescaping snippets internal to PATHNAME
be mindful of this distinction.

--
"A screaming comes across the sky.  It has happened before, but there is nothing to compare to it now."