Re: IPv6 addresses

On Jun 22, 2010, at 5:34, Thomas Leonard wrote:

> E doesn't work with IPv6 addresses. Here's a patch:
>
> http://gitorious.org/repo-roscidus/it-innovation/commit/5cda14106e59be94cda1aa013ee6422458025768
>
> This also adds "[]" to the list of acceptable URI characters.

Looks plausible to me; go ahead and commit, but only after adding some  
(updoc) unit tests for the parsing and printing.

> By the way, I found this surprising:
>
> $ ls
> a|b
>
> $ rune
> ? <file:a|b>.getText()
> # problem: <FileNotFoundException: .../a:b (No such file or  
> directory)>
>
> ? <file>["a|b"].getText()
> # problem: <FileNotFoundException: .../a:b (No such file or  
> directory)>
>
> ? for name in <file:.>.list() { println(<file>[name].getText()) }
> # problem: <FileNotFoundException: .../a/a:b (No such file or  
> directory)>
>
> Why does it do that?

Poorly-thought-out Windows compatibility. "|" is the conventional  
(including outside of E, IIRC) way to use a Windows drive letter in a  
URL without making it look like a URL scheme. There is also a rule  
such that <c:foo> (where c is any single letter) is actually  
<file:c:foo>.

I haven't looked into the issues here (e.g. whether removing this  
would break E on Windows) so I have no recommendations at the moment.

MarkM and I are of the opinion that it would be not a bad idea to make  
separate FileGetters (or whatever they would be called) for "the root  
of the filesystem" and "the current directory", since they are  
different sorts of authority. I've thought about making <file> stick  
to file-URL syntax (including %20s) since it's nominally and  
syntactically a URL; combining these two, there would then be a third  
object for "interpret platform filename syntax" including Windows  
drive letters, unescaped spaces, and relative paths.

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>