[Haskell-cafe] Re: File path programme

Glynn Clements writes: >> Well, there is a sort-of canonic version for every path; >> on most Unix systems the function realpath(3) will find >> it. My interpretation is that two paths are equivalent >> iff they point to the same target. > I think that any definition which includes an "iff"

Re: [Haskell-cafe] Re: File path programme

Peter Simons wrote: > > Hmmm, I'm not really sure what "equivalence" for file > > paths should mean in the presence of hard/symbolic links, > > (NFS-)mounted file systems, etc. > > Well, there is a sort-of canonic version for every path; on > most Unix systems the function realpath(3) will fi

Re: [Haskell-cafe] Re: File path programme

I have not been following this thread too closely, but I have looked at the various proposed implementations floating around and have a few comments. I noticed some have #ifdefs for platforms, which seems not very useful. I write not just cross-platform, but cross platform at the same time program

[Haskell-cafe] Re: File path programme

On 2005-01-31, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote: > Peter Simons <[EMAIL PROTECTED]> writes: > >> http://cryp.to/pathspec/PathSpec.hs > >> There also is a function which changes a path specification >> into its canonic form, meaning that all redundant segments >> are stripped. >

[Haskell-cafe] Re: File path programme

Sven Panne writes: > OK, but even paths which realpath normalizes to different > things might be the same (hard links!). Sure, but paths it normalizes to the same thing almost certainly _are_ the same. ;-) That's all I am looking for. In general, I think path normalization is a nice-to-have fea

Re: [Haskell-cafe] Re: File path programme

Well, there is a sort-of canonic version for every path; on most Unix systems the function realpath(3) will find it. Here is the BUGS listing from 'man realpath' on my system: Never use this function. It is broken by design since it is impossible to determine a suitable size for the output buffe

Re: [Haskell-cafe] Re: File path programme

Peter Simons wrote: Sven Panne writes: > Hmmm, I'm not really sure what "equivalence" for file > paths should mean in the presence of hard/symbolic links, > (NFS-)mounted file systems, etc. Well, there is a sort-of canonic version for every path; on most Unix systems the function realpath(3) wil

[Haskell-cafe] Re: File path programme

Sven Panne writes: > Hmmm, I'm not really sure what "equivalence" for file > paths should mean in the presence of hard/symbolic links, > (NFS-)mounted file systems, etc. Well, there is a sort-of canonic version for every path; on most Unix systems the function realpath(3) will find it. My inte

Re: [Haskell-cafe] Re: File path programme

This is a very good summary, and I'm interested to see what you come up with. robert dockins wrote: 1) File names are abstract entities. There are a number of ways one might concretely represent a filename. Among these ways are: a) A contiguous sequence of octets in memory (C

Re: [Haskell-cafe] Re: File path programme

Peter Simons <[EMAIL PROTECTED]> writes: > http://cryp.to/pathspec/PathSpec.hs > There also is a function which changes a path specification > into its canonic form, meaning that all redundant segments > are stripped. It's incorrect: canon (read "x/y/.." :: RelPath Posix) gives "x", yet on Uni

Re: [Haskell-cafe] Re: File path programme

Peter Simons wrote: >The module currently knows only _relative_ paths. I am still >experimenting with absolute paths because I have recently >learned that on Windows something like "C:foo.txt" is >actually relative -- not absolute. Very weird. "\foo.txt" is also relative on Win32. And "con.txt" is

Re: [Haskell-cafe] Re: File path programme

Peter Simons wrote: [...] There also is a function which changes a path specification into its canonic form, meaning that all redundant segments are stripped. So although two paths which designate the same target may not be equal, they can be tested for equivalence. Hmmm, I'm not really sure what "

[Haskell-cafe] Re: File path programme

Robert Dockins writes: > 1) File names are abstract entities. There are a number of > ways one might concretely represent a filename. Among these > ways are: > >a) A contiguous sequence of octets in memory > (C style string on most modern hardware) >b) A sequenc

Re: UTF-8 BOM, really!? (was: [Haskell-cafe] Re: File path programme)

On 2005 January 31 Monday 04:56, Graham Klyne wrote: > How can it make sense to have a BOM in UTF-8? UTF-8 is a sequence of > octets (bytes); what ordering is there here that can sensibly be varied? Correct. There is no order to be varied. A BOM came to be permitted because it uses the identica

Re: [Haskell-cafe] Re: File path programme

I have been ruminating on the various responses my attempted file path implementation has generated. I have a design beginning to form in the back of my head which attempts to address the file path problem as I lay out below. Before I develop it any further, are there any important considerati

UTF-8 BOM, really!? (was: [Haskell-cafe] Re: File path programme)

At 23:39 30/01/05 +0100, Marcin 'Qrczak' Kowalczyk wrote: Aaron Denney <[EMAIL PROTECTED]> writes: >> It provides variants of UTF-16/32 with and without a BOM, but >> UTF-8 only has the variant with a BOM. This makes UTF-8 a stateful >> encoding. > > I think you mean "UTF-8 only has the variant wit

Re: [Haskell-cafe] Re: File path programme

Marcin 'Qrczak' Kowalczyk writes: > AFAIK MacOS normalizes filenames, but using a slightly different > algorithm than Unicode (perhaps just an older version). According to , Mac OS X uses different forms depending on the file system. | For exampl

Re: [Haskell-cafe] Re: File path programme

Aaron Denney <[EMAIL PROTECTED]> writes: > Better yet would be to have the standard never allow the BOM. If I could decide, I would ban the BOM in UTF-8 altogetger, but I'm afraid the Unicode Consortium doesn't want to do this. Miscosoft Notepad puts a BOM in UTF-8 encoded files. -- __("<

[Haskell-cafe] Re: File path programme

On 2005-01-30, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote: > Aaron Denney <[EMAIL PROTECTED]> writes: > >>> It provides variants of UTF-16/32 with and without a BOM, but >>> UTF-8 only has the variant with a BOM. This makes UTF-8 a stateful >>> encoding. >> >> I think you mean "UTF-8 only

Re: [Haskell-cafe] Re: File path programme

Aaron Denney <[EMAIL PROTECTED]> writes: >> It provides variants of UTF-16/32 with and without a BOM, but >> UTF-8 only has the variant with a BOM. This makes UTF-8 a stateful >> encoding. > > I think you mean "UTF-8 only has the variant without a BOM". No, unfortunately. Unicode standard section

[Haskell-cafe] Re: File path programme

On 2005-01-30, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote: > Glynn Clements <[EMAIL PROTECTED]> writes: > >> And it isn't a theoretical issue. E.g. in an environment where EUC-JP >> is used, filenames may begin with $)B (designate JISX0208 to G1), >> or they may not (because G1 is assumed

Re: [Haskell-cafe] Re: File path programme

(BMarcin 'Qrczak' Kowalczyk wrote: (B (B> >> The various UTF encodings do not have this particular problem; if a UTF (B> >> string is valid, then it is a unique representation of a unicode string. (B> >> However, decoding is still a partial function and can fail. (B> > (B> > And while it is

Re: [Haskell-cafe] Re: File path programme

Stefan Monnier <[EMAIL PROTECTED]> writes: >> The various UTF encodings do not have this particular problem; if a UTF >> string is valid, then it is a unique representation of a unicode string. >> However, decoding is still a partial function and can fail. > > And while it is partly true, it is qu

[Haskell-cafe] Re: File path programme

> The various UTF encodings do not have this particular problem; if a UTF > string is valid, then it is a unique representation of a unicode string. > However, decoding is still a partial function and can fail. And while it is partly true, it is qualified by the problems relative to canonicalizati

[Haskell-cafe] Re: File path programme

Ben Rudiak-Gould writes: > 1. Programs using the library will have predictable > (exploitable) bugs in pathname handling. > 2. It will never be possible to change the current weird > behavior, because it might break legacy code. I completely agree. Handling file path specifications

[Haskell-cafe] Re: File path programme

On Tue, 25 Jan 2005 13:32:29 +0200, Krasimir Angelov <[EMAIL PROTECTED]> wrote: > >> What about splitFileExt "foo.bar."? ("foo", "bar.") or ("foo.bar.", "")? > > > > The latter makes more sense to me, as an extension of the first case > > you give and splitting "foo.tar.gz" to ("foo.tar", "gz"). >

Re: [Haskell-cafe] Re: File path programme

Marcin 'Qrczak' Kowalczyk wrote: These rules agree on "foo", "foo." and "foo.tar.gz", yet disagree on "foo.bar."; I don't know which is more natural. Filename extensions come from DOS 8.3 format. In these kind of names only one '.' is allowed. Unix does not have filename extensions, as '.' is ju

Re: [Haskell-cafe] Re: File path programme

Aaron Denney <[EMAIL PROTECTED]> writes: >> What about splitFileExt "foo.bar."? ("foo", "bar.") or ("foo.bar.", "")? > > The latter makes more sense to me, as an extension of the first case > you give and splitting "foo.tar.gz" to ("foo.tar", "gz"). It's not that obvious: both choices are compati

[Haskell-cafe] Re: File path programme

On 2005-01-23, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote: > What about splitFileExt "foo.bar."? ("foo", "bar.") or ("foo.bar.", "")? The latter makes more sense to me, as an extension of the first case you give and splitting "foo.tar.gz" to ("foo.tar", "gz"). -- Aaron Denney -><-