filepath: Library for manipulating FilePaths in a cross platform way.
A library for FilePath manipulations, using Posix or Windows filepaths
depending on the platform.
Both System.FilePath.Posix and System.FilePath.Windows provide the same interface. See either for examples and a list of the available functions.
[Skip to Readme]
Downloads
- filepath-1.3.0.2.tar.gz [browse] (Cabal source package)
- Package description (revised from the package)
Note: This package has metadata revisions in the cabal description newer than included in the tarball. To unpack the package including the revisions, use 'cabal get'.
Maintainer's Corner
For package maintainers and hackage trustees
Candidates
| Versions [RSS] | 1.0, 1.1.0.0, 1.1.0.1, 1.1.0.2, 1.1.0.3, 1.1.0.4, 1.2.0.0, 1.2.0.1, 1.3.0.0, 1.3.0.1, 1.3.0.2, 1.4.0.0, 1.4.1.0, 1.4.1.1, 1.4.1.2, 1.4.2, 1.4.2.1, 1.4.2.2, 1.4.100.0, 1.4.100.1, 1.4.100.2, 1.4.100.3, 1.4.100.4, 1.4.101.0, 1.4.102.0, 1.4.200.0, 1.4.200.1, 1.4.300.1, 1.4.300.2, 1.4.301.0, 1.5.0.0, 1.5.2.0, 1.5.3.0, 1.5.4.0 (info) |
|---|---|
| Change log | changelog.md |
| Dependencies | base (>=4 && <4.8) [details] |
| Tested with | ghc ==7.6.3, ghc ==7.6.2, ghc ==7.6.1, ghc ==7.4.2, ghc ==7.4.1, ghc ==7.2.2, ghc ==7.2.1, ghc ==7.0.4, ghc ==7.0.3, ghc ==7.0.2, ghc ==7.0.1, ghc ==6.12.3 |
| License | BSD-3-Clause |
| Author | Neil Mitchell |
| Maintainer | libraries@haskell.org |
| Revised | Revision 2 made by HerbertValerioRiedel at 2015年01月12日T09:18:07Z |
| Category | System |
| Home page | http://www-users.cs.york.ac.uk/~ndm/filepath/ |
| Bug tracker | https://github.com/haskell/filepath/issues |
| Source repo | head: git clone https://github.com/haskell/filepath.git this: git clone http://git.haskell.org/packages/filepath.git(tag filepath-1.3.0.2-release) |
| Uploaded | by HerbertValerioRiedel at 2014年03月21日T21:18:09Z |
| Distributions | Arch:1.4.300.1, Fedora:1.4.301.0 |
| Reverse Dependencies | 1832 direct, 13784 indirect [details] |
| Downloads | 69568 total (111 in the last 30 days) |
| Rating | 2.25 (votes: 2) [estimated by Bayesian average] |
| Your Rating |
|
| Status | Docs available [build log] Successful builds reported [all 1 reports] |
Readme for filepath-1.3.0.2
[back to package description]System.FilePath Build Status
I have written a System.FilePath module in part based on the one in
Yhc, and in part based on the one in Cabal (thanks to Lemmih). The aim
is to try and get this module into the base package, as FilePaths
are something many programs use, but its all too easy to hack up a
little function that gets it right most of the time on most platforms,
and there lies a source of bugs.
This module is Posix (Linux) and Windows capable - just import
System.FilePath and it will pick the right one. Of course, if you
demand Windows paths on all OSes, then System.FilePath.Windows will
give you that (same with Posix). Written in Haskell 98 with
Hierarchical Modules.
If you go to the Haddock page, there are a few little examples at the top of the re-exported module.
Acknowledgments
Thanks to Marc Webber, shapr, David House, Lemmih, others...
Competitors
System.FilePath from Cabal, by Lemmih FilePath.hs and
NameManip.hs from MissingH
The one from Cabal and FilePath.hs in MissingH are both very
similar, I stole lots of good ideas from those two.
NameManip.hs seems to be more unix specific, but all functions in
that module have equivalents in this new System.FilePath module.
Hopefully this new module can be used without noticing any lost functions, and certainly adds new features/functions to the table.
Should FilePath be an abstract data type?
The answer for this library is no. This is a deliberate design decision.
In Haskell 98 the definition is type FilePath = String, and all
functions operating on FilePaths, i.e. readFile/writeFile etc
take FilePaths. The only way to introduce an abstract type is to
provide wrappers for these functions or casts between Strings and
FilePathAbstracts.
There are also additional questions as to what constitutes a
FilePath, and what is just a pure String. For example,
"/path/file.ext" is a FilePath. Is "/" ? "/path" ? "path" ?
"file.ext" ? ".ext" ? "file" ?
With that being accepted, it should be trivial to write
System.FilePath.ByteString which has the same interface as
System.FilePath yet operates on ByteStrings.