Path >> fullName should not be the same as printString

So damien what is the solution?

Le 7/10/16 à 18:18, Damien Pollet a écrit :

Path >> printString returns a self-evaluating representation, which is fine. Its symmetric is thus Compiler >> evaluate: aString.

(Path from: aString) parses the unix/url representation of a path and results in a Path instance. As far as I understand, #fullName should be the symmetric of that, so that we always have (modulo syntactic normalization, maybe) :

(Path from: aString) fullName = aString

Note that there's an edge case with the empty string that is wrong (at least it should be confusing to unix guys):

Path from: ''. "Path root"

Usually the absolute path for the root of the filesystem is explicitly noted '/', and an empty path is equivalent to '.'

--

Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

It's a breaking change and I don't know if there's a way to do it with proper deprecation… my hope is that there are not many users of it, but I haven't checked yet. Any opinions among users of FileSystem?

On 8 October 2016 at 19:12, stepharo <[hidden email]> wrote:

So damien what is the solution?

Le 7/10/16 à 18:18, Damien Pollet a écrit :

Path >> printString returns a self-evaluating representation, which is fine. Its symmetric is thus Compiler >> evaluate: aString.

(Path from: aString) parses the unix/url representation of a path and results in a Path instance. As far as I understand, #fullName should be the symmetric of that, so that we always have (modulo syntactic normalization, maybe) :

(Path from: aString) fullName = aString

Note that there's an edge case with the empty string that is wrong (at least it should be confusing to unix guys):

Path from: ''. "Path root"

Usually the absolute path for the root of the filesystem is explicitly noted '/', and an empty path is equivalent to '.'

--

Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

--

Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

Its awkward to deal with. Some notes here...

https://pharo.fogbugz.com/default.asp?13094#154946

On Fri, Oct 14, 2016 at 12:05 AM, Damien Pollet <[hidden email]> wrote:

I explored a bit more and I'm stumped. Fixing it for Unix is easy, but it breaks Windows paths, because those use their first element to store the drive name (c: d: etc) which shouldn't be preceded by a /.

I'm starting to think the Absolute/Relative dichotomy is either wrong or incomplete and we need windows-specific subclasses. Doesn't it feel strange that we can pass strings with different syntax and assumptions to Path class >> from: and get instances from the same classes?

On 8 October 2016 at 19:21, Damien Pollet <[hidden email]> wrote:

It's a breaking change and I don't know if there's a way to do it with proper deprecation… my hope is that there are not many users of it, but I haven't checked yet. Any opinions among users of FileSystem?

On 8 October 2016 at 19:12, stepharo <[hidden email]> wrote:

So damien what is the solution?

Le 7/10/16 à 18:18, Damien Pollet a écrit :

Path >> printString returns a self-evaluating representation, which is fine. Its symmetric is thus Compiler >> evaluate: aString.

(Path from: aString) parses the unix/url representation of a path and results in a Path instance. As far as I understand, #fullName should be the symmetric of that, so that we always have (modulo syntactic normalization, maybe) :

(Path from: aString) fullName = aString

Note that there's an edge case with the empty string that is wrong (at least it should be confusing to unix guys):

Path from: ''. "Path root"

Usually the absolute path for the root of the filesystem is explicitly noted '/', and an empty path is equivalent to '.'

--

Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

--

Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

--

Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

On 10/13/2016 10:35 AM, Damien Pollet wrote:

Could you give an example what the file:// URLs look like when they contain a drive letter?

I'm afraid I don't have any Windows machines handy to see what Internet Explorer does, but as far as I can tell an absolute URL compliant with RFC 3986 might look something like

file:/c:/foo/bar

A relative URL that fits the URL syntax would be

file:c:/foo/bar

But I'm finding it difficult to tell precisely how RFCs 1738 and 3986 currently interact.

The discussion in this proposed RFC is somewhat interesting: https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-02, as it directly addresses Windows file naming. In appendix B.2, it says

"When mapping a DOS- or Windows-like file path to a URI, use the drive
   letter (e.g. "c:") as the first path segment. Some implementations leave the leading slash off before the drive letter.  "

and appendix C.1 deals with DOS file paths.


I hope this is more helpful than it is confusing.

Regards,

-Martin

All this already works (although maybe not perfectly in edge cases). Consider:

  'file:///C:/Users/tempfile.txt' asUrl.

  'file:///C:/Users/tempfile.txt' asUrl asFileReference.

  FileLocator C / 'Users' / 'tmpfile.txt'.

Where the last two are identical.

Note that relative file URLs do not exist.

> On 14 Oct 2016, at 13:28, Gabriel Cotelli <[hidden email]> wrote:
>
> At least Chrome uses this:
>
> file:///C:/Users/tempfile.txt
>
> On Fri, Oct 14, 2016 at 1:45 AM, Martin McClure <[hidden email]> wrote:
> On 10/13/2016 10:35 AM, Damien Pollet wrote:
> Could you give an example what the file:// URLs look like when they contain a drive letter?
>
> I'm afraid I don't have any Windows machines handy to see what Internet Explorer does, but as far as I can tell an absolute URL compliant with RFC 3986 might look something like
>
> file:/c:/foo/bar
>
> A relative URL that fits the URL syntax would be
>
> file:c:/foo/bar
>
> But I'm finding it difficult to tell precisely how RFCs 1738 and 3986 currently interact.
>
> The discussion in this proposed RFC is somewhat interesting: https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-02, as it directly addresses Windows file naming. In appendix B.2, it says
>
> "When mapping a DOS- or Windows-like file path to a URI, use the drive
>    letter (e.g. "c:") as the first path segment. Some implementations leave the leading slash off before the drive letter.  "
>
> and appendix C.1 deals with DOS file paths.
>
>
> I hope this is more helpful than it is confusing.
>
> Regards,
>
> -Martin
>
>
>