A simple directory-like tree datatype, with useful IO functions and Foldable and Traversable instance Provides a simple data structure mirroring a directory tree on the filesystem, as well as useful functions for reading and writing file and directory structures in the IO monad. Importing the library and optional (useful) Foldable and Traverable libraries: Write a hand-made directory tree of textfiles (strings) to the disk. Simulates creating a new user Tux's home directory on a unix machine: read a directory by opening all the files at a filepath with readFile, returning an 'AnchoredDirTree String' (d2). Then check for any IO failures: Use Foldable instance function to concat a directory dir of text files into a single file under the same directory: Open all the files in the current directory as lazy bytestrings, ignoring the base path in Anchored wrapper: This version also offers an experimental function readDirectoryWithL that does lazy directory IO, allowing you to treat the returned DirTree as if it were a normal lazily-generated data structure. For example, the following does only the amount of IO necessary to list the file names of the children of the root directory, similar to ls /: Any ideas or suggestions for improvements are most welcome :-) CHANGES: from 0.11 export System.Directory.Tree.transformDir as requested add test suite to cabal file remove redundant removeNonexistent (thanks to dmwit for patch).
directory-tree is a tool in the Build Automation category of a tech stack.
No pros listed yet.
No cons listed yet.
What are some alternatives to directory-tree?
A free and open-source package manager designed for the Microsoft development platform. It is also distributed as a Visual Studio extension.
It is a package manager for the Ruby programming language that provides a standard format for distributing Ruby programs and libraries, a tool designed to easily manage the installation of gems, and a server for distributing them.
Bower is a package manager for the web. It offers a generic, unopinionated solution to the problem of front-end package management, while exposing the package dependency model via an API that can be consumed by a more opinionated build stack. There are no system wide dependencies, no dependencies are shared between different apps, and the dependency tree is flat.
With Terraform, you describe your complete infrastructure as code, even as it spans multiple service providers. Your servers may come from AWS, your DNS may come from CloudFlare, and your database may come from Heroku. Terraform will build all these resources across all these providers in parallel.