Proposal: expose the drive functions in the filepath package
Hi all, This is proposal 1535: http://hackage.haskell.org/trac/ghc/ticket/1535 This comes out of http://hackage.haskell.org/trac/ghc/ticket/1490 where, in createDirectoryIfMissing, we use stat to determine if a directory exists. (I don't think catching an exception is a possibility in this case, as mkdir returns EEXIST if "pathname already exists (not necessarily as a directory)", so we can't distinguish between the directory already existing and a file existing with the name that we want. Short of doing something ugly like trying to make (path ++ "/.") and seeing if we get ENOTDIR, anyway). The problem is that mingw's stat succeeds for C:\ and C:\foo but fails for C: and C:\foo\. The current code strips a trailing \ before calling stat, and thus fails if asked to create C:\ (which we always do if "make parents" is true, and of course this path could be given explicitly by a user). What we want is something like if isDrive x then addTrailingPathSeparator x else dropTrailingPathSeparator x except filepath currently doesn't export isDrive, for reasons I'm not entirely clear on. Thus I propose exposing the *Drive functions from the filepath package. The patch, attached to the bug, is rather trivial as the code is already written, tested etc, just not exposed. Let's try until 21 July for a discussion period. Please try to accompany any objections with a (clean) alternative solution to the original problem. Thanks Ian
Hello Ian, Saturday, July 14, 2007, 4:39:33 PM, you wrote:
The problem is that mingw's stat succeeds for C:\ and C:\foo but fails for C: and C:\foo\. The current code strips a trailing \ before calling stat, and thus fails if asked to create C:\ (which we always do if "make parents" is true, and of course this path could be given explicitly by a user).
What we want is something like
if isDrive x then addTrailingPathSeparator x else dropTrailingPathSeparator x
well, i don't know FilePath library but if it has some sort of canonizeFilename function, this function should make this check yourself and shouldn't strip trailing '\' after ':' for obvious reason - 'c:' and 'c:\' are different directories -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Hi Bulat, On Sat, Jul 14, 2007 at 11:01:13PM +0400, Bulat Ziganshin wrote:
well, i don't know FilePath library but if it has some sort of canonizeFilename function, this function should make this check yourself and shouldn't strip trailing '\' after ':' for obvious reason - 'c:' and 'c:\' are different directories
The normalise function doesn't affect whether or not there is a trailing separator: Prelude System.FilePath.Windows> normalise "c:" "C:" Prelude System.FilePath.Windows> normalise "c:\\" "C:\\" Prelude System.FilePath.Windows> normalise "c:\\foo" "C:\\foo" Prelude System.FilePath.Windows> normalise "c:\\foo\\" "C:\\foo\\" Thanks Ian
Hello Ian, Sunday, July 15, 2007, 3:47:15 AM, you wrote:
well, i don't know FilePath library but if it has some sort of canonizeFilename function, this function should make this check yourself and shouldn't strip trailing '\' after ':' for obvious reason - 'c:' and 'c:\' are different directories
The normalise function doesn't affect whether or not there is a trailing separator:
Prelude System.FilePath.Windows> normalise "c:" "C:" Prelude System.FilePath.Windows> normalise "c:\\" "C:\\" Prelude System.FilePath.Windows> normalise "c:\\foo" "C:\\foo" Prelude System.FilePath.Windows> normalise "c:\\foo\\" "C:\\foo\\"
well, i mean that FilePath libarry should contain some sort of normalization function that omits '\' at end of path unless it's a ":\" combination. in other words, function that you now write should be a part of FilePath library because it's a standard functionality although this probably will not solve your problem if you need tro be compatible with existing FilePath version -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Hi Bulat, On Sun, Jul 15, 2007 at 12:01:00PM +0400, Bulat Ziganshin wrote:
well, i mean that FilePath libarry should contain some sort of normalization function that omits '\' at end of path unless it's a ":\" combination. in other words, function that you now write should be a part of FilePath library because it's a standard functionality
Ah, I see. Yes, that would work too, although I think Neil and I would prefer the more general *Drive functions being exposed (shout if I'm wrong, Neil).
although this probably will not solve your problem if you need tro be compatible with existing FilePath version
We don't. Thanks Ian
Hello Ian, Sunday, July 15, 2007, 3:03:20 PM, you wrote:
well, i mean that FilePath libarry should contain some sort of normalization function that omits '\' at end of path unless it's a ":\" combination. in other words, function that you now write should be a part of FilePath library because it's a standard functionality
Ah, I see. Yes, that would work too, although I think Neil and I would prefer the more general *Drive functions being exposed (shout if I'm wrong, Neil).
with direct use of *Drive function your code will become windows-specific. if the same functionality will be implemented inside FilePath library, you will use only portable canonize* function nevertheless, exporting *Drive and other internal functions will be great anyway - it's hard to predict all the possible ways of using library -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Hi Bulat, On Sun, Jul 15, 2007 at 05:33:57PM +0400, Bulat Ziganshin wrote:
Sunday, July 15, 2007, 3:03:20 PM, you wrote:
well, i mean that FilePath libarry should contain some sort of normalization function that omits '\' at end of path unless it's a ":\" combination. in other words, function that you now write should be a part of FilePath library because it's a standard functionality
Ah, I see. Yes, that would work too, although I think Neil and I would prefer the more general *Drive functions being exposed (shout if I'm wrong, Neil).
with direct use of *Drive function your code will become windows-specific.
Not so! Prelude System.FilePath.Posix> isDrive "" True Prelude System.FilePath.Posix> isDrive "/" True Prelude System.FilePath.Posix> isDrive "/foo" False Prelude System.FilePath.Posix> isDrive "/foo/" False
nevertheless, exporting *Drive and other internal functions will be great anyway - it's hard to predict all the possible ways of using library
I agree. Thanks Ian
Hi
Neil is on holiday.
Neil is, but just saw this thread - although I think this makes it clear why we need two week discussion periods - the deadline expires before I get back to the UK! I'm happy to expose the drive functions, its a trivial change, since they get exposed for testing anyway. The first version of the filepath library did expose them, and people complained, so I hid them. Looking at the implementation of many of the higher level filepath functions, to get them just right, you need the drive distinction. This makes me suspect that to implement other functions on top of filepath, you will also need the drive functions. I'm broadly in favour of this - Igloo has a concrete use case that can be done no other way so we definately need to solve it somehow. Whether his particular function wants adding is another question. Thanks Neil
participants (4)
-
Bulat Ziganshin -
Ian Lynagh -
Malcolm Wallace -
Neil Mitchell