On Sat, Jul 29, 2006 at 05:35:30PM -0700, Andrew Pimlott wrote:
On Sat, Jul 29, 2006 at 02:59:06AM +0200, Udo Stenzel wrote:
Andrew Pimlott wrote:
Second, foo is just as good a directory
as foo/ to the system
...unless you have both (think Reiser4) or you want to create the file
(I
Andrew Pimlott wrote:
On Thu, Jul 27, 2006 at 09:59:37PM +0200, Udo Stenzel wrote:
In fact, that's consistent with the current documentation, because
* getFileName foo == foo
* getFileName foo/ ==
I have to disagree with that.
No, you don't. That's the current behaviour of Neil
Andrew Pimlott wrote:
On Wed, Jul 26, 2006 at 05:06:41PM -0400, David Roundy wrote:
This doesn't apply uniformly to all programs--except that we can say
that any path with a trailing '/' is intended to be a directory, and
if it's not, then that's an error.
I thought some more about this,
On Thu, 2006-07-27 at 11:07 -0700, Andrew Pimlott wrote:
On Wed, Jul 26, 2006 at 04:02:31PM -0700, Andrew Pimlott wrote:
I admit I don't know enough to say how the lpt1 issue should be
handled. Is there any Win32 call I can make that will help me avoid
accidentally opening these magic
On Thu, Jul 27, 2006 at 09:59:37PM +0200, Udo Stenzel wrote:
Andrew Pimlott wrote:
After all, the trailing slash has no real
meaning for any intermediate processing you might do.
Here I beg to differ. I'd expect:
* setFileName foo bar == bar
* setFileName foo/ bar == foo/bar
In
On Wed, Jul 26, 2006 at 04:02:31PM -0700, Andrew Pimlott wrote:
I admit I don't know enough to say how the lpt1 issue should be
handled. Is there any Win32 call I can make that will help me avoid
accidentally opening these magic files? Say, if I call open with
O_CREAT | O_EXCL?
On Wed, Jul 26, 2006 at 05:06:41PM -0400, David Roundy wrote:
cp(1), for example, treats paths with trailing separators differently
from paths without.
This doesn't apply uniformly to all programs--except that we can say
that any path with a trailing '/' is intended to be a directory, and
Hi
hahaha! I admit I don't know enough to say how the lpt1 issue should be
handled. Is there any Win32 call I can make that will help me avoid
accidentally opening these magic files?
No, because its entirely possible to open these magic files, you'll
just find that accidentally your output
On Thu, 2006-07-27 at 11:07 -0700, Andrew Pimlott wrote:
On Wed, Jul 26, 2006 at 04:02:31PM -0700, Andrew Pimlott wrote:
I admit I don't know enough to say how the lpt1 issue should be
handled. Is there any Win32 call I can make that will help me avoid
accidentally opening these magic
On 7/26/06, Neil Mitchell [EMAIL PROTECTED] wrote:
The main purpose of canoncialPath is to fix the case on Windows, so
c:\my documents\file.doc becomes C:\My Documents\file.doc if that
is the case correct version of the file. I think this function will
not actually change the file with relation
On Wed, Jul 26, 2006 at 03:36:13AM +0100, Neil Mitchell wrote:
pathSeparator :: Char
The character that seperates directories.
So what do I do with this? If I need it, it seems like the module has
failed.
Hopefully no one will ever use it. Its part of the low level functions
that the
I'd just point out that I'm not aware of an operating system that GHC
runs on that doesn't accept '/' as a path separator. It may be that
you could fine an OS where you could compile with jhc or run with hugs
that doesn't use '/' (e.g. MacOS 9), but support for MacOS 9 at this
stage I wouldn't
Andrew Pimlott wrote:
The drive functions stand on their own as a chunk, and are possibly
not well suited to a Posix system, but are critical for a Windows
system.
Why are they critical for portable code? I am fine with
Windows-specific functions, but I think it's a mistake to bundle
On Wed, 2006-07-26 at 15:29 +0200, Udo Stenzel wrote:
My criticism is that your properties are all specified in terms of
string manipulation.
Exactly. I believe, a FilePath should be an algebraic datatype.
Most operations on that don't have to be specified, because they are
simple and
On Jul 26, 2006, at 1:47 PM, Neil Mitchell wrote:
Hi,
Perhaps instead:
directoryOf :: FilePath - String
filenameOf :: FilePath - String
extensionOf :: FilePath - String
basenaneOf :: FilePath - String
replaceFilename = joinFilePath . directoryOf
replaceDirectory = flip
Duncan Coutts wrote:
On Wed, 2006-07-26 at 15:29 +0200, Udo Stenzel wrote:
Exactly. I believe, a FilePath should be an algebraic datatype.
We've had this discussion before. The main problem is that all the
current IO functions (readFile, etc) use the FilePath type, which is
just a
On Wed, Jul 26, 2006 at 03:36:13AM +0100, Neil Mitchell wrote:
Its a rats nest to do it properly, but some very basic idea of does
this path have things which there is no way could possibly be in a
file - for example c:\|file is a useful thing to have.
This seems to encourage the classic
On Wed, Jul 26, 2006 at 03:29:01PM +0200, Udo Stenzel wrote:
Andrew Pimlott wrote:
Also, it looks from this that you treat paths differently depending on
whether they end in a separator. Yet this makes no difference to the
system. That seems wrong to me.
Not to the system, but some
On Wed, Jul 26, 2006 at 04:34:50PM +0100, Duncan Coutts wrote:
On Wed, 2006-07-26 at 15:29 +0200, Udo Stenzel wrote:
Exactly. I believe, a FilePath should be an algebraic datatype.
Most operations on that don't have to be specified, because they are
simple and have an obvious effect. Add
Hi
So what's better?
- use an ADT (correct and portable by construction), convert to String
when calling the IO library
- fumble with Strings, use an unholy mix of specialized and general
functions, trip over a corner case
Or provide an ADT, demand people marshal to and from this ADT
Hi
Ok, this is a good use case. What should wget do if isValid fails?
isValid (makeValid x) == True
makeValid is system dependant, and unspecified in its behaviour,
although obviously some kind of closeness to the original would be
ideal. So what if isValid fails and we don't have this?
On Wed, 2006-07-26 at 19:41 +0200, Udo Stenzel wrote:
Duncan Coutts wrote:
On Wed, 2006-07-26 at 15:29 +0200, Udo Stenzel wrote:
Exactly. I believe, a FilePath should be an algebraic datatype.
We've had this discussion before. The main problem is that all the
current IO functions
On Wed, 2006-07-26 at 11:32 -0700, Andrew Pimlott wrote:
On Wed, Jul 26, 2006 at 03:36:13AM +0100, Neil Mitchell wrote:
Its a rats nest to do it properly, but some very basic idea of does
this path have things which there is no way could possibly be in a
file - for example c:\|file is a
On Wed, Jul 26, 2006 at 08:19:47PM +0100, Neil Mitchell wrote:
Ok, this is a good use case. What should wget do if isValid fails?
makeValid is system dependant, and unspecified in its behaviour,
although obviously some kind of closeness to the original would be
ideal. So what if isValid
On Wed, Jul 26, 2006 at 11:39:40AM -0700, Andrew Pimlott wrote:
On Wed, Jul 26, 2006 at 03:29:01PM +0200, Udo Stenzel wrote:
Andrew Pimlott wrote:
Also, it looks from this that you treat paths differently depending on
whether they end in a separator. Yet this makes no difference to the
Hi
re: isValid
Perhaps we should be more specific and make it talk about illegal file
name characters if that is indeed the use case. Perhaps we should
provide a system-dependent list of characters that are not allowed in
file names. For example, on windows that would include '?'.
Then an
Andrew Pimlott wrote:
Maybe the trailing slash is important enough to take into account.
No, not the trailing slash. The difference between a directory and its
contents is important enough. This is ususally encoded using a trailing
slash, but I'd rather not worry about that detail in a
On Wed, Jul 26, 2006 at 10:32:02PM +0100, Neil Mitchell wrote:
Sorry, I meant to say what I think wget should do. IMO, it should have
a conservative set of allowed characters, encode the filename into that
Not enough, because of the LPT1 issue - unless you add L as a
disallowed letter :)
Udo Stenzel [EMAIL PROTECTED] writes:
No, not the trailing slash. The difference between a directory and its
contents is important enough. This is ususally encoded using a trailing
slash, but I'd rather not worry about that detail in a program.
What does Emacs do with double separators?
At Wed, 26 Jul 2006 23:07:36 +0200,
Udo Stenzel wrote:
What does Emacs do with double separators? I'm at a loss thinking of
anything they could denote, but it could be useful.
You mean like,
/path/to/somewhere//with/double/seperator
If so, it treats it as if you had typed in:
First, http://java.sun.com/j2se/1.5.0/docs/api/java/io/File.html may be useful
to compare to. I learned C:\ is an absolute and C: is a relative path.
What are the use cases? I can see four different types of file paths that one
will want to manipulate. The following are all pure functions:
[Sorry for the late reply.]
On Wed, Jul 19, 2006 at 03:16:48AM +0100, Neil Mitchell wrote:
I want to make sure a filename is valid. For example, prn and con
This is another rat's nest, so I suggest that it be dealt with
separately from the basic filepath module. The notion of valid is
Hi
Its a rats nest to do it properly, but some very basic idea of does
this path have things which there is no way could possibly be in a
file - for example c:\|file is a useful thing to have.
This seems to encourage the classic mistake of checking not known bad
rather than known good.
Neil Mitchell wrote:
And if someone wants to define a new and better FilePath type, I
would prefer something more abstract, such as a list of Path
components, with functions to serialize it as a String and to parse
it from a String.
A list of path components is just not enough, I'm afraid.
Neil Mitchell writes:
We should avoid referring to $PATH as the path, since we
already have FilePath.
Agreed, but I couldn't come up with a better name, if anyone has any
suggestions.
searchPath?
--
David Menendez [EMAIL PROTECTED] http://www.eyrie.org/~zednenem/
Hi
I want to make sure a filename is valid. For example, prn and con
This is another rat's nest, so I suggest that it be dealt with
separately from the basic filepath module. The notion of valid is
squishy: It depends entirely on what you intend to do with the path.
Its a rats nest to do
Hi,
In this library proposal, there are a bunch of xxxDrive functions ..
[remove them]
I strongly agree about this.
I have decided you are right, on Windows getDrive x can be written simply as:
getDrive x | isRelative x =
| otherwise = head (getDirectories x)
And given that
On 18/07/06, Stephane Bortzmeyer [EMAIL PROTECTED] wrote:
For instance, many lazy (not in the Haskell meaning) programmers
believe that the path is safe if it does not include .. but it is
false (hint: ../foo/bar is a legal path on Unix).
I believe this does not cause trouble. If it is a shell
Stephane Bortzmeyer wrote:
On Mon, Jul 17, 2006 at 03:07:51AM +0100,
Neil Mitchell [EMAIL PROTECTED] wrote
a message of 64 lines which said:
How about adding something like restrictFilePaths :: FilePath - IO
() which will restrict the area that can be played with to that
beneath the given
On Sun, Jul 16, 2006 at 08:43:31PM -0500, Brian Smith wrote:
I kind of expect that a Haskell library for file paths will use the
type system to ensure some useful properties about the paths.
It's a nice idea, but I claim that it's a rat's nest. Path semantics,
when you look hard at them, are
On Mon, Jul 17, 2006 at 03:07:51AM +0100, Neil Mitchell wrote:
Hi Brian,
I kind of expect that a Haskell library for file paths will use the
type system to ensure some useful properties about the paths.
I am specificially concentrating on type FilePath = String, because
that is how it is
Hi Neil,On 7/17/06, Neil Mitchell [EMAIL PROTECTED] wrote:
Hi Brian,You sent this email just to me, and not to the list. If you indendedto send to the list then feel free to forward my bits on to the list. I know that FilePath is defined by Haskell '98 as a String and so it cannot
be changed. So,
Hi
I disagree. It would be trivial to create a new module that exported new
definitions of file IO actions that operated on GoodPath instead of
FilePath, transparently delegating to the original readFile/writeFile/etc.
until they could be removed in the future. This would also support the
43 matches
Mail list logo
