On Sun, Jan 30, 2005 at 09:25:00PM +0100, Marcin 'Qrczak' Kowalczyk wrote:
> David Roundy <[EMAIL PROTECTED]> writes:
>
> > No, it's not Unix-specific, it's portable. If you want to write
> > portable C code, you have to use the standard library, which means
> > that file names are represented as
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 to contain JISX0208 initally).
I think such encodings are never used as d
David Roundy <[EMAIL PROTECTED]> writes:
> No, it's not Unix-specific, it's portable. If you want to write
> portable C code, you have to use the standard library, which means
> that file names are represented as Ptr CChar.
I disagree. We are talking about portable Haskell, not portable C.
The n
Glynn Clements <[EMAIL PROTECTED]> writes:
>> Then of course there's the issue that Win32 edge
>> labels are Unicode, while Posix edge labels are [Word8]. Hmm.
>
> Strictly speaking, they're [CChar], but I doubt that anyone will ever
> implement Haskell on a platform where a byte isn't 8 bits wid
Ben Rudiak-Gould wrote:
> Is there an MSDN page that actually gives a grammar, or at least a
> taxonomy, of Win32 pathnames? That would be useful.
It would also be longer than "War and Peace", once you start allowing
for MS-DOS "8.3" pathnames, codepages, the fact that anything anywhere
which c
robert dockins wrote:
> > I don't pretend to fully understand various unicode standard but it
> > seems to me that these problems are deeper than file path library. The
> > equation (decode . encode)
> > /= id seems confusing for me. Can you give me an example when this
> > happen?
>
> I am pre
On Sun, Jan 30, 2005 at 02:17:01PM +, Glynn Clements wrote:
> Ben Rudiak-Gould wrote:
> > > pathToForeign :: p -> IO (Ptr CChar)
> > > pathFromForeign :: Ptr CChar -> IO p
> >
> > This interface is problematic. Is the pointer returned by pathToForeign
> > a heap pointer which the caller is
Keean Schupke wrote:
> >I guess it's just that I'm more concerned with making possible what is
> >currently impossible (according to the library standards)--that is, using
> >FFI and IO on the same file--rather than just adding utility features that
> >application developers could have written th
Ben Rudiak-Gould wrote:
> Symbolic links complicate things a bit, since they are followed like
> edges but are actually paths.
Actually, they're essentially arbitrary byte strings. The OS doesn't
automatically require them to be valid paths.
Most of the API functions to which you might pass a
I don't pretend to fully understand various unicode standard but it
seems to me that these problems are deeper than file path library. The
equation (decode . encode)
/= id seems confusing for me. Can you give me an example when this
happen?
I am pretty sure that ISO 2022 encoded strings can have m
On Thu, 27 Jan 2005 16:31:21 -0500, robert dockins
<[EMAIL PROTECTED]> wrote:
> > I don't pretend to fully understand various unicode standard but it
> > seems to me that these problems are deeper than file path library. The
> > equation (decode . encode)
> > /= id seems confusing for me. Can you g
I don't pretend to fully understand various unicode standard but it
seems to me that these problems are deeper than file path library. The
equation (decode . encode)
/= id seems confusing for me. Can you give me an example when this
happen? What can we do when the file name is passed as command lin
Even simple manipulations break in the presence of encoding issues, or
even just of unusual paths. What is the extension of "\\.\TAPE0" ? Its
not "\TAPE0". BTW this is a valid path on Windows 2000 upwards. If you
don't care about corner cases, then you have no worries. It would be
nice to
- Keep the existing System.IO API the same. openFile, createDirectory
... will take the file path as string.
The problem is that "string" means different things in haskell and in C.
A C "string" is really just a contiguous sequence of octets in memory.
A haskell string has a particular interpreta
John Meacham <[EMAIL PROTECTED]> writes:
> too bad we can't do things like
>
> #if exists(module System.Path)
> import System.Path
> #else
> ...
> #endif
>
> I still find it perplexing that there isn't a decent standard haskell
> preprocessor
For my language Kogut I designed a syntax
if
While true, I don't see what this has to do with the choice between
PathStart and Maybe PathRoot. The types are isomorphic; we can detect
and simplify the /.. case either way.
True
Because of the above problem, I'm willing to treat path fragments
(Relative in both lattices) as a special case. Bu
Gregory Wright <[EMAIL PROTECTED]> writes:
> Actually, Common Lisp specifies a special data type to handle
> logical filepaths, which are distinct from file path strings. Having
> had to debug common lisp code that uses this (written by other
> people) I've observed that this attempt to do the "Ri
Robert Dockins <[EMAIL PROTECTED]> writes:
> More than you would think, if you follow the conventions of modern
> unix shells. eg, "foo/.." is always equal to ".",
For the OS it's not the same if foo is a non-local symlink.
Shells tend to resolve symlinks themselves on cd, and "cd .." means
to r
Hello,
On Jan 27, 2005, at 10:46 AM, Krasimir Angelov wrote:
Hello Guys,
Let me propose another solution which is simpler (at least from my
point of view)and will not break the existing. When I designed the API
of the original System.FilePath library I looked at OS.Path modules
from Python and ML.
Hello Guys,
Let me propose another solution which is simpler (at least from my
point of view)and will not break the existing. When I designed the API
of the original System.FilePath library I looked at OS.Path modules
from Python and ML. They both uses plain string to keep the file path
but does p
Robert Dockins wrote:
>This is true in a sense, but I think making the distinction explicit is
>helpful for a number of the operations we want to do. For example, what
>is the parent of the relative path "."? Answer is "..". What is the
>parent of "/." on unix? Answer is "/.".
While true, I don
Warning: I'm not interested in a path parsing/combining library, so my
criticisms are perhaps unrelated to your goals.
One thing that I'd be interested in seeing for any Path class would be a
simple instance for FilePath (or String, if you want to imagine FilePath
will be changed). Not everyone w
Jules Bean wrote:
only it isn't. That's a property of a shell, the underlying OS allows
spaces in file names with no need for an escaping mechanism.
Okay, that was a mistake... but it does not change the point, that
pathToString needs to work out what platform it
is on, and doing it without typec
On Thu, Jan 27, 2005 at 11:33:21AM +, Keean Schupke wrote:
>
> >I guess it's just that I'm more concerned with making possible what is
> >currently impossible (according to the library standards)--that is, using
> >FFI and IO on the same file--rather than just adding utility features that
> >a
On 27 Jan 2005, at 11:33, Keean Schupke wrote:
Except paths are different on different platforms... for example:
/a/b/../c/hello\ there/test
and:
A:\a\b\
notice how the backslash is used to 'escape' a space or meta-character
on
only it isn't. That's a property of a shell, the underlying OS allows
I guess it's just that I'm more concerned with making possible what is
currently impossible (according to the library standards)--that is, using
FFI and IO on the same file--rather than just adding utility features that
application developers could have written themselves. I suppose we don't
need
On Wed, Jan 26, 2005 at 10:20:12PM -0500, Robert Dockins wrote:
> class (Show p) => Path p where
> isAbsolute :: p -> Bool
> isRelative :: p -> Bool
> isRelative = not . isAbsolute
> basename :: p -> String
> parent :: p -> p
> pathAppend :: p -> p -> p
> pathExtend :: p -> String ->
Ben Rudiak-Gould wrote:
I'm tentatively opposed to (B), since I think that the only
interesting difference between Win32 and Posix paths is in the set of
starting points you can name. (The path separator isn't very
interesting.) But maybe it does make sense to have separate
starting-point ADTs
Georg Martius wrote:
Hi,
I think Isaac's idea is pretty nice, to have an easy way to add
documentation in a collaborative manner.
I have the following in mind:
A separate wiki which supports generating haddock documentation.
Ideally one would see the haddock documentation as it is and would
clic
Here is my first cut at this. The unix implementation mostly works, the
windows one just has some datatypes sketched out, but it typechecks.
-- module FilePath where
import Data.Word (Word8)
import Text.ParserCombinators.Parsec
import Text.ParserCombinators.Parsec.Error
import System (getArgs)
> I would say that all paths are relative to something, whether it's the
> Unix root, or the current directory, or whatever. Therefore I would call
> this something like PathStart, and add:
>
> | CurrentDirectory
> | CurrentDirectoryOfWindowsDrive Char
> | RootOfCurrentWindowsDrive
On Wed, Jan 26, 2005 at 01:39:01PM -, Simon Marlow wrote:
> On 25 January 2005 19:45, Duncan Coutts wrote:
>
> > On Tue, 2005-01-25 at 19:12 +, Ben Rudiak-Gould wrote:
> >> My concern here is that someone will actually use the library once it
> >> ships, with the following consequences:
>
robert dockins wrote:
> After the discussion about file paths over the last several days I
went home and put together a quick trial implementation for unix file
paths, with the idea of adding windows, SMB and maybe VMS (why not?) paths.
This is great. Comments below.
> data PathRoot
>= UnixF
Hi,
I think Isaac's idea is pretty nice, to have an easy way to add documentation
in a collaborative manner.
I have the following in mind:
A separate wiki which supports generating haddock documentation. Ideally one would see
the haddock documentation as it is and would click to a function or typ
After the discussion about file paths over the last several days I went
home and put together a quick trial implementation for unix file paths,
with the idea of adding windows, SMB and maybe VMS (why not?) paths. It
is based on a Path class. I'll post it later when I get home. However,
I wil
On Wed, Jan 26, 2005 at 01:39:01PM -, Simon Marlow wrote:
> We can't add libraries in a point release, because there's no way for
> code to use conditional compilation to test the patchlevel version
> number.
On the other hand, darcs doesn't rely on version numbers when looking for
libraries (
On Wed, Jan 26, 2005 at 01:34:39PM -, Simon Marlow wrote:
> ... We can therefore:
>
> (a) make System.IO.FilePath be the new type, which is different from,
> and incompatible with, IO.FilePath. Similarly for
> System.IO.openFile, System.Directory.removeFile, and so on.
>
> (b) o
On 25 January 2005 19:45, Duncan Coutts wrote:
> On Tue, 2005-01-25 at 19:12 +, Ben Rudiak-Gould wrote:
>> My concern here is that someone will actually use the library once it
>> ships, with the following consequences:
>>
>> 1. Programs using the library will have predictable
>> (exploit
[ moving to [EMAIL PROTECTED] ]
On 26 January 2005 12:22, Malcolm Wallace wrote:
>> Could we just punt this library for this release. After all we can
>> add libraries in a later point release (eg 6.4.1) you just can't
>> change existing APIs.
>
> FWIW, I agree with Duncan, Ben, and Peter, that
> Could we just punt this library for this release. After all we can add
> libraries in a later point release (eg 6.4.1) you just can't change
> existing APIs.
FWIW, I agree with Duncan, Ben, and Peter, that the new System.FilePath
interface is broken, and the implementation more so. It would be
Mark Carroll <[EMAIL PROTECTED]> writes:
> On Tue, 25 Jan 2005, Marcin 'Qrczak' Kowalczyk wrote:
> (snip)
>> If problems are in the implementation but the interface is right, then
>> the module should be provided. It can be fixed later.
> (snip)
>
> A lot of the Haskell libraries are sufficiently
On Tue, 25 Jan 2005, Marcin 'Qrczak' Kowalczyk wrote:
(snip)
> If problems are in the implementation but the interface is right, then
> the module should be provided. It can be fixed later.
(snip)
A lot of the Haskell libraries are sufficiently poorly documented that I
work out what they do by exp
On Tue, 2005-01-25 at 19:12 +, Ben Rudiak-Gould wrote:
> My concern here is that someone will actually use the library once it
> ships, with the following consequences:
>
> 1. Programs using the library will have predictable (exploitable)
> bugs in pathname handling.
>
> 2. It will
Jules Bean wrote:
> [...] it is an extension of the notion that "/foo/" and "/foo"
> refer to the same directory. (Except, apparently, in the presence
> of symbolic links... or so I have some vague memory)
Yes, "/foo/" is equivalent to "/foo/.", which is not always the same as
"/foo". If "/foo" is
Ben Rudiak-Gould <[EMAIL PROTECTED]> writes:
> >Doing a reasonable job on System.FilePath, even if it isn't
> >perfect, will help prevent lots of applications from falling into
> >common traps, and help make more code portable.
>
> But the library code itself falls into the same traps! It's a g
Simon Marlow wrote:
>Doing a reasonable job on System.FilePath, even if it isn't perfect,
>will help prevent lots of applications from falling into common traps,
>and help make more code portable.
But the library code itself falls into the same traps! It's a great
example of the kind of code we sh
On 24 January 2005 22:11, Ben Rudiak-Gould wrote:
> Please, let's not ship this with the hierarchical libraries. It's not
> ready for prime time.
We decided to provide this library for purely pragmatic reasons. It's
better than nothing.
http://www.haskell.org/pipermail/libraries/2004-October/
On Tue, Jan 25, 2005 at 01:32:29PM +0200, Krasimir Angelov wrote:
> > splitFileName "/foo/bar" ==> ("/foo","bar")
> > splitFileName "/foo//bar" ==> ("/foo/","bar")
> >(definitely a bug)
>
> Is "/foo//bar" valid file path and what does "//" mean?
"//" means the same thing as "/". In unix yo
On 25 Jan 2005, at 11:32, Krasimir Angelov wrote:
splitFileName "/foo/bar" ==> ("/foo","bar")
splitFileName "/foo//bar" ==> ("/foo/","bar")
(definitely a bug)
Is "/foo//bar" valid file path and what does "//" mean?
pathParents "/foo///bar" ==> ["/","/foo","/foo","/foo","/foo/bar"]
Again what
Hello, Guys
The System.FilePath might not be perfect and might not handle some
unusual cases very well. Most of functions in this module are
collected from Cabal/Alex/Happy/Haddock. Some of these tools already
use their own functions for file path handling. Special care was taken
to make them more
Isaac Jones wrote:
>You might be interested in the new FilePath module that's in the
>works. There's been a lot of work to make these functions portable.
>
>http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/System/FilePath.hs
I didn't realize this was in CVS. IMHO this library is de
At 15:17 20/01/05 -0500, Mark Carroll wrote:
I tried writing a little command-line utility to find the relative path of
one thing from another thing (with Unix-like systems in mind). ...
FWIW, there's logic to do something like this in my URI module [1]. Bear
in mind that there is not, in general
Isaac Jones <[EMAIL PROTECTED]> writes:
> You might be interested in the new FilePath module that's in the
> works. There's been a lot of work to make these functions portable.
>
> http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/System/FilePath.hs
splitFileExt "foo" = ("foo", ""
You might be interested in the new FilePath module that's in the
works. There's been a lot of work to make these functions portable.
http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/System/FilePath.hs
peace,
isaac
___
Haskell-Cafe m
I tried writing a little command-line utility to find the relative path of
one thing from another thing (with Unix-like systems in mind). For example,
$ ./pathfromof /etc/init.d/ /etc/X11/XF86Config-4
../X11/XF86Config-4
$ ./pathfromof /tmp/baz/ /tmp/foo/
.
$ ls -l /tmp/baz
lrwxr-xr-x 1 markc mar
55 matches
Mail list logo