[Haskell-cafe] RE: ANN: System.FilePath 0.9

Neil Mitchell ndmitchell at gmail.com
Wed Jul 26 17:32:02 EDT 2006


>> 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 application can decide for itself what to do about that
> depending on the context. It might be able to tell the user to pick a
> different name, or in the wget case replace it with a different
> character or remove it or something.

Unfortunately thats too much work for the user of the API. Since it
tends to work on Posix, people probably won't go to the hassle of
fixing it up. If they have a "simple fix" then there is at least a
chance that they'll accept a patch that fixes the behaviour on
Windows. The only options that I can see are either you want it fixed,
or you want to get the user to fix it manually - both are catered for.

And on Windows its more complex, LPT1.txt is also an invalid file, but
LPT1.txt.txt isn't. Trying to express the weirdness of Windows is
probably beyond the chances of an API :)

> So maybe we should keep isValid but specify exactly what it checks.
I'm happy to specify things in more detail, at the moment its pretty
much a no-op on Posix, but if any Posix user suggests thats wrong I'll
happily fix it up.

> 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 :)

> > Haskell makes the difference, runInteractiveCommand vs runInteractiveProcess
> I'm not following.

Having some considerations towards a real path, one that can be used
on the command is reasonable, I think, because Haskell has functions
within it that distinguish between firing something at the underlying
filepath vs at the console. I don't however think its worth having a
special type for working with emacs, unless you have
System.FilePath.Emacs, given that Emacs is almost an operating system

> But the trouble is that if you
> silently drop the '/', then the only way for me to implement a correct
> cp(1) in Haskell is to not use your proposed interface for pathname
> handling, which drops this information.
Ok, now I remember the reasons I kept the trailing slash, I'll leave
it in. Esp the risers4 issue.



More information about the Haskell-Cafe mailing list