Commit Graph

287 Commits

Author SHA1 Message Date
687a113252
Fix documentation in System.Posix.FilePath 2016-05-09 17:04:01 +02:00
86a4b9ade2
Add IO modules, previously from HSFM 2016-05-09 16:53:31 +02:00
6638cd8cc1
Create HPath.IO module, adding canonicalizePath again 2016-05-09 14:40:30 +02:00
4ce35b9bec
TESTS: minor doctest cleanup 2016-05-09 14:17:12 +02:00
196647a383
Move some functionality from HPath to System.Posix.FilePath
This also removes 'canonicalizePath' from HPath which fixes
the doctest.
2016-05-09 14:16:53 +02:00
cfe626b6d4
Update README 2016-05-09 13:37:21 +02:00
a946387330
Merge posix-paths into hpath 2016-05-09 13:31:20 +02:00
1263fac7ec
Update submodule 2016-05-02 19:10:40 +02:00
45b515d1db
Add withAbsPath/withRelPath/withFnPath 2016-04-17 18:09:50 +02:00
a5360f29a3
Don't re-export functions 2016-04-16 19:21:19 +02:00
f1875da780
Use latest posix-paths
Pending upstream PR.
2016-04-16 19:12:23 +02:00
7e8c745e35
Clean up, rewrite stuff 2016-04-16 18:17:44 +02:00
577ecf6750
Add normalizeAbs, which may or may not be useful 2016-04-15 14:23:25 +02:00
8f7e5806e3
Be more strict
* don't rely on OverloadedString
* make basename fail if run on root dir "/"
* reject "." and ".." in filename parser
* reject ".." in path parsers
* normalise paths in parsers
2016-04-15 14:23:07 +02:00
c570505297
Add hiddenFile function 2016-04-10 21:50:52 +02:00
148eeb619f
Implement String -> ByteString and vice versa conversion for filepaths 2016-04-05 00:55:25 +02:00
877d8c4089
Implement equalFilePath 2016-04-05 00:54:55 +02:00
8c1bd139c0
Readd TH constructors 2016-04-05 00:54:36 +02:00
bd71947b2a
Use word8 package 2016-04-04 18:46:25 +02:00
491efe44a3
Use ByteString for paths instead of String 2016-04-04 17:29:35 +02:00
hasufell
c7229061d0 Fix encoding issues with realPath 2016-04-04 03:06:22 +02:00
3a52a9ea4b
Add getAllParents 2016-04-03 16:20:38 +02:00
3c3a2d2766
Switch to new layout 2016-03-30 02:47:42 +02:00
d15e4b8ad9 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 22:53:42 +01:00
Chris Done
e2974d3152 Bump to 0.5.7 2016-03-06 17:43:49 +01:00
Chris Done
dbee82c69b Merge pull request #14 from felixonmars/patch-1
Fix a haddock parse error
2016-03-06 17:43:02 +01:00
Felix Yan
05271c94af Fix a haddock parse error
The line was triggering parse error when running haddock:

```
src/Path.hs:16:1:
    parse error on input ‘-- | A normalizing well-typed path type.’
```

Removing it works for me.
2016-03-05 13:44:08 +08:00
Chris Done
9d357b24c8 Remove redundant check for /= . or .. 2016-03-04 15:11:06 +01:00
Chris Done
62c681819c Update test suite 2016-03-04 15:09:21 +01:00
Chris Done
c41fa86d17 Bump to 0.5.6 2016-03-04 15:07:00 +01:00
Chris Done
04608e0e53 Reject only .. and . (#13) 2016-03-04 15:06:27 +01:00
Chris Done
47450b5dd6 Bump to 0.5.5 2016-03-04 14:50:28 +01:00
Chris Done
540c24f3a5 Use FilePath.isValid (#12) 2016-03-04 14:49:21 +01:00
Chris Done
b9b921db84 Bump to 0.5.4 2016-03-04 14:41:16 +01:00
Chris Done
2e109c86d8 Reject path consisting of all "." (fixes #13)
Ping @mrkkrp
2016-03-04 14:39:17 +01:00
Chris Done
04fa5d3ea8 Merge pull request #9 from magthe/ClarifyRelative
Clarify what limitations the RelX parsers have.
2016-03-04 14:29:52 +01:00
Chris Done
88eb4f32a8 Merge pull request #12 from mrkkrp/master
Improve description of the package
2016-01-31 11:37:59 +00:00
mrkkrp
01d0f5c968 Add standard header to the ‘Path’ module
The header is nice to have, it's displayed in Haddocks.
2016-01-28 18:10:27 +06:00
mrkkrp
c281f3755e Add year 2016 to copyright notices 2016-01-28 18:10:09 +06:00
mrkkrp
d6674c5ee1 Improve the ‘README.md’ file
Here I copied the blog post announcing the library, because it describes
it very well, and not everyone who discovers the library will know where
to look for such a comprehensive description.

http://chrisdone.com/posts/path-package

I've made two edits to that post to reflect new things:

1. On line 123 there is a mention of ‘fromAbsDir’ and other similar
   functions.

2. On line 363 I've put a link to my ‘path-io’ package that provides
   well-typed interface to ‘directory’ and ‘temporary’. I've written the
   package for my personal needs, because I was tired of the endless
   conversion and I wanted things like recursive copying of
   directories. When I published it, someone opened an issue asking to
   add some functions from Stack's ‘Path.IO’ — that's what I'm going to
   do. I expect it will be able to replace ‘Path.IO’ in Stack soon. I've
   talked to Stack maintainers and they like the package and have
   nothing against the switch.
2016-01-28 18:02:41 +06:00
mrkkrp
de73f8b4ea Improve synopsis and description 2016-01-28 17:47:15 +06:00
Chris Done
9fee9e42da Merge pull request #11 from mrkkrp/master
Fix a typo
2016-01-17 20:31:14 +00:00
mrkkrp
36cc9af231 Fix a typo 2016-01-16 17:22:34 +06:00
Chris Done
9af2a76b2e Merge pull request #10 from rimmington/nfdata
Add NFData instance for Path
2016-01-15 10:23:50 +00:00
Rhys
cd470f2d11 Add NFData instance for Path 2016-01-15 12:07:27 +11:00
Magnus Therning
b5cff315a1 Clarify what limitations the RelX parsers have.
Signed-off-by: Magnus Therning <magnus@therning.org>
2016-01-07 16:15:06 +01:00
Chris Done
28c4f7fe21 Bump to 0.5.3 2015-11-21 19:54:59 +01:00
Chris Done
95fab22567 Merge pull request #7 from mrkkrp/master
Various improvements
2015-11-21 19:53:16 +01:00
mrkkrp
00fabad1f4 Add type-safe synonyms of ‘toFilePath’
This helps to “double check” programmers' assumptions about what kind of
path he is converting into ‘FilePath’. Without these synonyms it's
possible to silently convert wrong type of path into ‘FilePath’.
2015-11-21 16:15:34 +06:00
mrkkrp
733fa04ac3 Write ‘isPrefixOf’ and friends in infix form 2015-11-21 16:14:54 +06:00