[plt-scheme] 352.8

Matthew Flatt skrev:

> More details:
> 
> Under Unix, (split-path "a/~") now returns the path form of "./~" as
> its second argument, instead of just "~", since "~" is an absolute
> path. To keep things symmetric, (build-path "a" "./~") produces the
> path form of "a/~". In other words, "./" is used as a kind of encoding
> prefix for relative paths that start with "~". Under Windows, there are
> many, many more encoding examples, such as "\\\\?\\REL\\a " to
> represent the name of a file that ends in a space (since trailing
> spaces are normally ignored in Windows paths).

I'd love to be able to work with Windows paths on Unix
and vice versa. In the old days split-path behaved differently
on Windows and Unix due to different interpretations of \.

Example:

   Windows PLT 301:
   > (split-path (string->path "\\foo\\bar\\baz.txt"))
   #<path:\foo\bar\>
   #<path:baz.txt>
   #f


   Unix PLT 301:
   > (split-path (string->path "\\foo\\bar\\baz.txt"))
   relative
   #<path:\foo\bar\baz.txt>
   #f

Since the path above was constructed with string->path I
think it is okay to get different results. It would however
be nice to have string->windows-path and string->unix-path
so that one can work with Windows paths on Unix and
vice versa.

The same problem occurs when the external representation
of a path is read - this is somewhat problematic, since
paths are abstract - and thus read/write ought to
preserve directory structure.

Consider:

   On Windows (with output "quux.txt":
   (write (string->path "\\foo\\bar\\baz.txt"))

   On Unix (with input from "quuz.txt")
   (read)

Should this return this path:

   1)  "/foo/bar/baz.txt"

or this

   2)  "\\foo\\bar\\baz.txt" ?

I prefer 1), since 1) is interpreted as
the two folders foo and bar and a filename bar.txt
(which was the original interpretation).

The other option 2) is on the other hand interpreted
as one filename with embedded backslashes.

Alternatively provide an official windows-path->unix-path.

[ I ran into this problem today moving the index
   of my search engine from Windows to Unix. The index
   was saved with the help of (lib "serialize.ss")
   and contained some paths.

   This seems to work for my purpose, but since paths are
   tricky, I am sure it won't hold long under scrutiny:

     (define (windows-path->unix-path path)
        (string->path
          (regexp-replace* "\\\\"
                           (path->string path)
                           "/")))

]


-- 
Jens Axel Søgaard