Fork chrisdone's path library
I wasn't happy with the way it dealt with Dir vs File things. In his
version of the library, a `Path b Dir` always ends with a trailing
path separator and `Path b File` never ends with a trailing path separator.
IMO, it is nonsensical to make a Dir vs File distinction on path level,
although it first seems nice.
Some of the reasons are:
* a path is just that: a path. It is completely disconnected from IO level
and even if a `Dir`/`File` type theoretically allows us to say "this path
ought to point to a file", there is literally zero guarantee that it will
hold true at runtime. So this basically gives a false feeling of a
type-safe file distinction.
* it's imprecise about Dir vs File distinction, which makes it even worse,
because a directory is also a file (just not a regular file). Add symlinks
to that and the confusion is complete.
* it makes the API oddly complicated for use cases where we basically don't
care (yet) whether something turns out to be a directory or not
Still, it comes also with a few perks:
* it simplifies some functions, because they now have guarantees whether a
path ends in a trailing path separator or not
* it may be safer for interaction with other library functions, which behave
differently depending on a trailing path separator (like probably shelly)
Not limited to, but also in order to fix my remarks without breaking any
benefits, I did:
* rename the `Dir`/`File` types to `TPS`/`NoTPS`, so it's clear we are only
giving information about trailing path separators and not actual file
types we don't know about yet
* add a `MaybeTPS` type, which does not mess with trailing path separators
and also gives no guarantees about them... then added `toNoTPS` and
`toTPS` to allow type-safe conversion
* make some functions accept more general types, so we don't unnecessarily
force paths with trailing separators for `(</>)` for example... instead
these functions now examine the paths to still have correct behavior.
This is really minor overhead. You might say now "but then I can append
filepath to filepath". Well, as I said... we don't know whether it's a
"filepath" at all.
* merge `filename` and `dirname` into `basename` and make `parent` be
`dirname`, so the function names match the name of the POSIX ones,
which do (almost) the same...
* fix a bug in `basename` (formerly `dirname`) which broke the type
guarantees
* add a pattern synonym for easier pattern matching without exporting
the internal Path constructor
2016-03-08 21:53:42 +00:00
|
|
|
# HPath
|
2015-05-08 12:35:05 +00:00
|
|
|
|
2016-05-18 23:29:08 +00:00
|
|
|
[](https://gitter.im/hasufell/hpath?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge) [](https://hackage.haskell.org/package/hpath) [](http://travis-ci.org/hasufell/hpath)
|
2016-05-09 16:06:40 +00:00
|
|
|
|
2016-05-09 11:31:20 +00:00
|
|
|
Support for well-typed paths in Haskell. Also provides ByteString based filepath
|
|
|
|
|
manipulation.
|
2016-01-28 11:47:46 +00:00
|
|
|
|
|
|
|
|
## Motivation
|
|
|
|
|
|
Fork chrisdone's path library
I wasn't happy with the way it dealt with Dir vs File things. In his
version of the library, a `Path b Dir` always ends with a trailing
path separator and `Path b File` never ends with a trailing path separator.
IMO, it is nonsensical to make a Dir vs File distinction on path level,
although it first seems nice.
Some of the reasons are:
* a path is just that: a path. It is completely disconnected from IO level
and even if a `Dir`/`File` type theoretically allows us to say "this path
ought to point to a file", there is literally zero guarantee that it will
hold true at runtime. So this basically gives a false feeling of a
type-safe file distinction.
* it's imprecise about Dir vs File distinction, which makes it even worse,
because a directory is also a file (just not a regular file). Add symlinks
to that and the confusion is complete.
* it makes the API oddly complicated for use cases where we basically don't
care (yet) whether something turns out to be a directory or not
Still, it comes also with a few perks:
* it simplifies some functions, because they now have guarantees whether a
path ends in a trailing path separator or not
* it may be safer for interaction with other library functions, which behave
differently depending on a trailing path separator (like probably shelly)
Not limited to, but also in order to fix my remarks without breaking any
benefits, I did:
* rename the `Dir`/`File` types to `TPS`/`NoTPS`, so it's clear we are only
giving information about trailing path separators and not actual file
types we don't know about yet
* add a `MaybeTPS` type, which does not mess with trailing path separators
and also gives no guarantees about them... then added `toNoTPS` and
`toTPS` to allow type-safe conversion
* make some functions accept more general types, so we don't unnecessarily
force paths with trailing separators for `(</>)` for example... instead
these functions now examine the paths to still have correct behavior.
This is really minor overhead. You might say now "but then I can append
filepath to filepath". Well, as I said... we don't know whether it's a
"filepath" at all.
* merge `filename` and `dirname` into `basename` and make `parent` be
`dirname`, so the function names match the name of the POSIX ones,
which do (almost) the same...
* fix a bug in `basename` (formerly `dirname`) which broke the type
guarantees
* add a pattern synonym for easier pattern matching without exporting
the internal Path constructor
2016-03-08 21:53:42 +00:00
|
|
|
The motivation came during development of
|
|
|
|
|
[hsfm](https://github.com/hasufell/hsfm)
|
|
|
|
|
which has a pretty strict File type, but lacks a strict Path type, e.g.
|
|
|
|
|
for user input.
|
|
|
|
|
|
|
|
|
|
The library that came closest to my needs was
|
|
|
|
|
[path](https://github.com/chrisdone/path),
|
|
|
|
|
but the API turned out to be oddly complicated for my use case, so I
|
|
|
|
|
decided to fork it.
|
|
|
|
|
|
2016-05-09 11:31:20 +00:00
|
|
|
Similarly, [posix-paths](https://github.com/JohnLato/posix-paths)
|
|
|
|
|
was exactly what I wanted for the low-level operations, but upstream seems dead,
|
|
|
|
|
so it is forked as well and merged into this library.
|
|
|
|
|
|
2016-05-09 15:37:33 +00:00
|
|
|
## Goals
|
|
|
|
|
|
|
|
|
|
* well-typed paths
|
|
|
|
|
* high-level API to file operations like recursive directory copy
|
|
|
|
|
* safe filepath manipulation, never using String as filepath, but ByteString
|
|
|
|
|
* still allowing sufficient control to interact with the underlying low-level calls
|
|
|
|
|
|
2016-05-24 13:55:36 +00:00
|
|
|
Note: this library was written for __posix__ systems and it will probably not support other systems.
|
|
|
|
|
|
Fork chrisdone's path library
I wasn't happy with the way it dealt with Dir vs File things. In his
version of the library, a `Path b Dir` always ends with a trailing
path separator and `Path b File` never ends with a trailing path separator.
IMO, it is nonsensical to make a Dir vs File distinction on path level,
although it first seems nice.
Some of the reasons are:
* a path is just that: a path. It is completely disconnected from IO level
and even if a `Dir`/`File` type theoretically allows us to say "this path
ought to point to a file", there is literally zero guarantee that it will
hold true at runtime. So this basically gives a false feeling of a
type-safe file distinction.
* it's imprecise about Dir vs File distinction, which makes it even worse,
because a directory is also a file (just not a regular file). Add symlinks
to that and the confusion is complete.
* it makes the API oddly complicated for use cases where we basically don't
care (yet) whether something turns out to be a directory or not
Still, it comes also with a few perks:
* it simplifies some functions, because they now have guarantees whether a
path ends in a trailing path separator or not
* it may be safer for interaction with other library functions, which behave
differently depending on a trailing path separator (like probably shelly)
Not limited to, but also in order to fix my remarks without breaking any
benefits, I did:
* rename the `Dir`/`File` types to `TPS`/`NoTPS`, so it's clear we are only
giving information about trailing path separators and not actual file
types we don't know about yet
* add a `MaybeTPS` type, which does not mess with trailing path separators
and also gives no guarantees about them... then added `toNoTPS` and
`toTPS` to allow type-safe conversion
* make some functions accept more general types, so we don't unnecessarily
force paths with trailing separators for `(</>)` for example... instead
these functions now examine the paths to still have correct behavior.
This is really minor overhead. You might say now "but then I can append
filepath to filepath". Well, as I said... we don't know whether it's a
"filepath" at all.
* merge `filename` and `dirname` into `basename` and make `parent` be
`dirname`, so the function names match the name of the POSIX ones,
which do (almost) the same...
* fix a bug in `basename` (formerly `dirname`) which broke the type
guarantees
* add a pattern synonym for easier pattern matching without exporting
the internal Path constructor
2016-03-08 21:53:42 +00:00
|
|
|
## Differences to 'path'
|
|
|
|
|
|
2016-05-09 11:31:20 +00:00
|
|
|
* doesn't attempt to fake IO-related information into the path, so whether a path points to a file or directory is up to your IO-code to decide...
|
2016-04-16 16:17:44 +00:00
|
|
|
* trailing path separators will be preserved if they exist, no messing with that
|
|
|
|
|
* uses safe ByteString for filepaths under the hood instead of unsafe String
|
|
|
|
|
* fixes broken [dirname](https://github.com/chrisdone/path/issues/18)
|
|
|
|
|
* renames dirname/filename to basename/dirname to match the POSIX shell functions
|
|
|
|
|
* introduces a new `Path Fn` for safe filename guarantees and a `RelC` class
|
|
|
|
|
* allows pattern matching via unidirectional PatternSynonym
|
|
|
|
|
* uses simple doctest for testing
|
|
|
|
|
* allows `~/` as relative path, because on posix level `~` is just a regular filename that does _NOT_ point to `$HOME`
|
|
|
|
|
* remove TH, it sucks
|
2016-01-28 11:47:46 +00:00
|
|
|
|
2016-05-09 11:31:20 +00:00
|
|
|
## Differences to 'posix-paths'
|
|
|
|
|
|
2016-05-09 11:37:21 +00:00
|
|
|
* uses the `word8` package for save word8 literals instead of `OverloadedStrings`
|
2016-05-23 11:52:34 +00:00
|
|
|
* `hasTrailingPathSeparator` and `dropTrailingPathSeparator` behave in the same way as their `System.FilePath` counterpart
|
|
|
|
|
* added various functions:
|
|
|
|
|
* `equalFilePath`
|
2016-05-24 13:36:34 +00:00
|
|
|
* `getSearchPath`
|
2016-05-23 11:52:34 +00:00
|
|
|
* `hasParentDir`
|
|
|
|
|
* `hiddenFile`
|
2016-05-24 13:36:34 +00:00
|
|
|
* `isFileName`
|
|
|
|
|
* `isValid`
|
|
|
|
|
* `makeRelative`
|
|
|
|
|
* `makeValid`
|
|
|
|
|
* `normalise`
|
|
|
|
|
* `splitSearchPath`
|
|
|
|
|
* `stripExtension`
|
2016-05-23 11:52:34 +00:00
|
|
|
* has a custom versions of `openFd` which allows more control over the flags than its unix package counterpart
|
|
|
|
|
* adds a `getDirectoryContents'` version that works on Fd
|
2016-05-09 11:37:21 +00:00
|
|
|
|
2016-05-30 14:02:08 +00:00
|
|
|
## Examples in ghci
|
|
|
|
|
|
|
|
|
|
Start ghci via `cabal repl`:
|
|
|
|
|
|
|
|
|
|
```hs
|
|
|
|
|
-- enable OverloadedStrings
|
|
|
|
|
:set -XOverloadedStrings
|
|
|
|
|
-- import HPath.IO
|
|
|
|
|
import HPath.IO
|
|
|
|
|
-- parse an absolute path
|
|
|
|
|
abspath <- parseAbs "/home"
|
|
|
|
|
-- parse a relative path (e.g. user users home directory)
|
|
|
|
|
relpath <- parseRel "jule"
|
|
|
|
|
-- concatenate paths
|
|
|
|
|
let newpath = abspath </> relpath
|
|
|
|
|
-- get file type
|
|
|
|
|
getFileType newpath
|
|
|
|
|
-- return all contents of that directory
|
|
|
|
|
getDirsFiles newpath
|
|
|
|
|
-- return all contents of the parent directory
|
|
|
|
|
getDirsFiles (dirname newpath)
|
|
|
|
|
```
|
|
|
|
|
|
