yogsototh/haskell-turtle-library
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
No description
259 commits 1 branch 0 tags 392 KiB
Haskell 100%
Find a file
Paul Capron 5522d66d11 Make mv work accross filesystems 
This commit fixes Gabriel439/Haskell-Turtle-Library#37

On a POSIX OS, Prelude.mv would fail if the two given paths are not on
the same filesystem. That’s because under the hood mv simply calls
Filesystem.rename[1], which on POSIX forwards to the rename syscall[2],
and (most implementations of) rename don’t work with files on different
filesystems.

This commit makes mv catch any error returned by Filesystem.rename and,
when an error is triggered because one tries to do an across-filesystem
move, resort to using a (non-atomic) "Filesystem.copyFile followed by
Filesystem.removeFile" combo to move the file. That way Prelude.mv behaves
similarly to POSIX mv[3]. Note however that, unlike POSIX mv, an across-fs
*directory* moving is (still) not supported.

Detecting why exactly Filesystem.rename failed is the tricky part.
On error, it returns a standard IOError[4], which is an opaque type.
We can get the error type[5] of this error. But the standard 2010 Haskell
only defines a limited set of common error types (EOF, already exists, …),
which does not cover the failure we are interested in (i.e.: rename
syscall returned EXDEV[6] “Invalid cross-device link”). Hence in our case,
Filesystem.rename throws an IOError with an unclassified type that
we cannot for sure relate to an across-fs issue.

We can get more precision about IO errors if we are willing to depend on
GHC-only stuff. Given that GHC is de facto *the* Haskell compiler, we are
OK to trade compiler-independance for much better handling of our case.

GHC exports a bunch of new IOErrorType on top of the standard ones.
For the failure we are concerned with, the IOErrorType is
UnsupportedOperation. This type is also used by GHC for a bunch of other
unusual errors[7], but among the possible errors returned by rename
(according to the POSIX spec and most implementations man pages), only
EXDEV is mapped to UnsupportedOperation (according to Foreign.C.Error
source code). Hence if we get an UnsupportedOperation from
Filesystem.rename, we can assume that it is because of an across-fs issue.

Note that we could be absolutely sure that the IOError is caused by EXDEV
if we were willing to be even less portable/more brittle:

  import Foreign.C.Error (Errno(Errno), eXDEV)
  import GHC.IO.Exception (ioe_errno)

  mv oldPath newPath = liftIO $ catchIOError (Filesystem.rename oldPath newPath)
   (\ioe -> if fmap Errno (ioe_errno ioe) == Just eXDEV
                then do
                    Filesystem.copyFile oldPath newPath
                    Filesystem.removeFile oldPath
                else ioError ioe)

But it seems that as-precise-as-possible error diagnostic at the price of
such dependence on GHC internals and low-level stuff is not worth it.
Checking against UnsupportedOperation, while not theoretically perfect, seems
good enough.

1: https://hackage.haskell.org/package/system-fileio-0.3.16.3/docs/Filesystem.html#v:rename
2: http://pubs.opengroup.org/onlinepubs/9699919799/functions/rename.html
3: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/mv.html
4: https://hackage.haskell.org/package/base-4.7.0.1/docs/System-IO-Error.html#t:IOError
5: https://hackage.haskell.org/package/base-4.7.0.1/docs/System-IO-Error.html#t:IOErrorType
6: http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_03.html
7: https://hackage.haskell.org/package/base-4.7.0.0/docs/src/Foreign-C-Error.html#errnoToIOError
2015-10-07 15:09:44 +02:00
bench Benchmark the bounded combinator 2015-05-12 23:46:02 +03:00
slides Updated slides 2015-09-03 14:58:18 -07:00
src Make mv work accross filesystems 2015-10-07 15:09:44 +02:00
test Added more format specifiers 2015-01-19 21:52:51 -08:00
.gitignore Add .gitignore for build artifacts 2015-05-14 04:59:05 +03:00
.travis.yml Added .travis.yml 2015-01-28 19:05:57 -08:00
LICENSE Initial commit 2015-01-17 18:52:18 -08:00
README.md Update README.md to use Stack 2015-08-13 16:25:18 +03:00
Setup.hs Initial commit 2015-01-17 18:52:18 -08:00
turtle.cabal Version 1.2.1 => 1.2.2 2015-09-27 09:31:11 -07:00

README.md

Turtle v1.2.1

Turtle is a reimplementation of the Unix command line environment in Haskell so that you can use Haskell as a scripting language or a shell. Think of turtle as coreutils embedded within the Haskell language.

Quick start

  • Install Stack

  • stack setup && stack install turtle

Then fire up ghci:

$ stack ghci
Prelude> :set -XOverloadedStrings
Prelude> import Turtle

... and try out some basic filesystem operations:

Prelude Turtle> cd "/tmp"
Prelude Turtle> mkdir "test"
Prelude Turtle> touch "test/foo"
Prelude Turtle> testfile "test/foo"
True
Prelude Turtle> rm "test/foo"
Prelude Turtle> testfile "test/foo"
False
Prelude Turtle> rmdir "test"
Prelude Turtle> view (lstree "/usr/lib")
FilePath "/usr/lib/gnome-screensaver"
FilePath "/usr/lib/gnome-screensaver/gnome-screensaver-dialog"
FilePath "/usr/lib/libplist.so.1.1.8"
FilePath "/usr/lib/tracker"
FilePath "/usr/lib/tracker/tracker-miner-fs"
FilePath "/usr/lib/tracker/tracker-extract"
FilePath "/usr/lib/tracker/tracker-writeback"
FilePath "/usr/lib/tracker/tracker-search-bar"
FilePath "/usr/lib/tracker/tracker-store"
FilePath "/usr/lib/libgif.so.4.1"
...

To learn more, read the turtle tutorial.

Goals

The turtle library focuses on being a "better Bash" by providing a typed and light-weight shell scripting experience embedded within the Haskell language. If you have a large shell script that is difficult to maintain, consider translating it to a "turtle script" (i.e. a Haskell script using the turtle library).

Among typed languages, Haskell possesses a unique combination of features that greatly assist scripting:

  • Haskell has global type inference, so all type annotations are optional
  • Haskell is functional and not object-oriented, so boilerplate is minimal
  • Haskell can be type-checked and interpreted quickly (< 1 second startup time)

Features

  • Batteries included: Command an extended suite of predefined utilities

  • Interoperability: You can still run external shell commands

  • Portability: Works on Windows, OS X, and Linux

  • Exception safety: Safely acquire and release resources

  • Streaming: Transform or fold command output in constant space

  • Patterns: Use typed regular expressions that can parse structured values

  • Formatting: Type-safe printf-style text formatting

  • Modern: Supports text and system-filepath

Development Status

Build Status

turtle's types and idioms are reasonably complete and I don't expect there to be significant changes to the library's core API. The only major functionality that I might add in the future would be to wrap optparse-applicative in a simpler API.

The set of available tools currently covers as many filesystem utilities as I could find across Hackage, but I would like to continue to add to the set of available tools to minimally match coreutils.

Community Resources

How to contribute

  • Contribute more utilities

  • Write turtle tutorials

License (BSD 3-clause)

Copyright (c) 2015 Gabriel Gonzalez All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name of Gabriel Gonzalez nor the names of other contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.