[plt-scheme] 352.8

Matthew Flatt skrev:
> At Sun, 22 Oct 2006 10:50:12 +0200, Jens Axel Søgaard wrote:
>>> For example, it's not clear what to use under Unix
>>> for the Windows root "C:\\" or "\\\\machine\\volume" or
>>> "\\?\#^%$#^@\\\\", 
>> Can't they just stay Windows paths? Manipulations like build-path
>> and split-paths can be used to tear old Windows paths apart, and
>> put new ones together - they can then later on be used on a
>> Windows machine? On a Unix-machine open-input-file on could
>> raise an exception, when called with a non-convertible
>> Windows path.
> 
> Yes - that's what I had in mind for direct support in MzScheme.
> 
> My impression was that you also needed the paths to somehow access
> parts of a Unix filesystem, in which case someone would have to do more
> work. If not, then nevermind.

Well. Until now I only need to transform the Windows-path
into a url that people can click at. The paths has this
form:

     c:\foo\bar \part\I\need.txt

and I just need "the end" of the path.

Having found some space on the web-server [*], I can have
a copy of the file repository at the web-server. This
mean that I now need to replace the beginning of windows
path with /home/soegaard/ to get

    /home/soegaard/ part/I/need.txt

With my simple paths, I can simply replace \ with /
and convert back-and-forth between paths and strings.

[*] If you promise not to tell anyone, I'll reveal that
I found 168Mb. Where? Well, I couldn't get the
size of my home directory to match the reported total
size, so I went looking. It turned out, I had a mail
account, I don't use. The spam received took up 168Mb.

>>> what to do with a Unix path element like "a\\b" or a Windows path
>>> element "a/b".

>> How about a parameter convert-seperators-in-paths which when true
>> converts between \\ and /, and if false doesn't? The default
>> being true, since that is probably most needed?
> 
> I think we're talking past each other a bit here. If we've stopped
> talking about using Windows paths to access a Unix filesystem, then the
> above is moot. If we're still talking about that a little, my intended
> point was that "\\" isn't a separator for Unix paths, and "/" isn't
> always a separator for Windows paths, so they can appear in element
> names (which makes the element name unsuitable on the other platform,
> independent of the rest of the path syntax).

I see two different uses:

   1. A Windows path is constructed on a Unix-machine,
      which is then sent to a Windows-machine (or
      perhaps written in a Database and later read)

   2. On Unix taking apart a Windows-path, and then build a
      Unix-path with the pieces.

For 2. to work the \\ need to be interpreted as seperators
and not as part of a file name.

You do have to examples of awful Windows-path, that I don't
really know what to dow with - but I hope most
paths are as simple as:

    c:\foo\bar\baz.txt

Would be helpfult to require the external represenatation
of a Windows path to be normalized?

-- 
Jens Axel Søgaard