FilePath is:module

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. Given the example FilePath: /directory/file.ext We can use the following functions to extract pieces. And we could have built an equivalent path with the following expressions:
  • "/directory" </> "file.ext".
  • "/directory/file" <.> "ext".
  • "/directory/file.txt" -<.> "ext".
Each function in this module is documented with several examples, which are also used as tests. Here are a few examples of using the filepath functions together: Example 1: Find the possible locations of a Haskell module Test imported from module Main:
[replaceFileName path_to_main "Test" <.> ext | ext <- ["hs","lhs"] ]
Example 2: Download a file from url and save it to disk:
do let file = makeValid url
System.Directory.createDirectoryIfMissing True (takeDirectory file)
Example 3: Compile a Haskell file, putting the .hi file under interface:
takeDirectory file </> "interface" </> (takeFileName file -<.> "hi")
References: [1] Naming Files, Paths and Namespaces (Microsoft MSDN)
Internal stuff: support for ByteString FilePaths
Internal stuff: support for ByteString FilePaths
A module for FilePath operations exposing System.FilePath plus some additional operations. Windows note: The extension methods (<.>, takeExtension etc) use the Posix variants since on Windows "//*" <.> "txt" produces "//*\\.txt" (which is bad for FilePattern values).
# Opaque implementation for FilePath The underlying type of a FilePath is a ByteArray. It is indeed like this because for some systems (Unix systems) a FilePath is a null terminated array of bytes. # FilePath and FileName for type checking validation In order to add some constraint at compile time, it is not possible to append (</>) a FilePath to another FilePath. You can only append (</>) a FileName to a given FilePath.
The equivalent of System.FilePath on raw (byte string) file paths. Not all functions of System.FilePath are implemented yet. Feel free to contribute!
Utilities for dealing with YAML config files which contain relative file paths.
A drop-in replacement of Data.ByteString from the bytestring package that provides file I/O functions with RawFilePath instead of FilePath.
Welcome to RawFilePath, a small part of the Haskell community's effort to purge String for the Greater Good. With this package, you can interact with the Unix system without the file path encoding issue or the StringByteString conversion overhead.

Rationale

Traditional String is notorious:
  • 24 bytes (three words) required for one character (the List constructor, the actual Char value, and the pointer to the next List constructor). 24x memory consumption.
  • Heap fragmentation causing malloc/free overhead
  • A lot of pointer chasing for reading, devastating the cache hit rate
  • A lot of pointer chasing plus a lot of heap object allocation for manipulation (appending, slicing, etc.)
  • Completely unnecessary but mandatory conversions and memory allocation when the data is sent to or received from the outside world
FilePath is a type synonym of String. This is a bigger problem than what String already has, because it's not just a performance issue anymore; it's a correctness issue as there is no encoding information. A syscall would give you (or expect from you) a series of bytes, but String is a series of characters. But how do you know the system's encoding? NTFS is UTF-16, and FAT32 uses the OEM character set. On Linux, there is no filesystem-level encoding. Would Haskell somehow magically figure out the system's encoding information and encode/decode accordingly? Well, there is no magic. FilePath has completely no guarantee of correct behavior at all, especially when there are non-ASCII letters. With this library, you use RawFilePath which is a sequence of bytes (instead of characters). You have the full control of decoding from (or encoding to) these bytes. This lets you do the job properly.

Usage

This is the top-level module that re-exports the sub-modules. Therefore, you can
import RawFilePath
to import all functions. For documentation, see: For process-related functions, see RawFilePath.Process for a brief introduction and an example code.