shelly
shell-like (systems) programming in Haskell
https://github.com/yesodweb/Shelly.hs
Version on this page: | 1.6.8.3 |
LTS Haskell 22.39: | 1.12.1@rev:1 |
Stackage Nightly 2024-10-31: | 1.12.1@rev:1 |
Latest on Hackage: | 1.12.1@rev:1 |
shelly-1.6.8.3@sha256:971c77dd8ee47e83fa818db610f8c757b822e9a537f38e4219d2b8a6800ea480,5033
Module documentation for 1.6.8.3
Shelly
Shelly provides a single module for convenient systems programming in Haskell.
- is aimed at convenience and getting things done rather than being a demonstration of elegance.
- has detailed and useful error messages
- maintains its own environment, making it thread-safe
- is modern, using Text and system-filepath/system-fileio
- has low memory usage
run_
and other underscore variants that don’t return stdoutrunFoldLines
to run a fold operation over each line rather than loading all of stdout into memoryrunHandle
andrunHandles
for complete control over handles
Looking to put your Haskell learning to immediate practical use? You don’t have to create artifical intelligence, try just automating some of your boring tasks.
The focus of this library on convenience combined with good error messages should make shelly approachable for newer users of Haskell.
I have published an introductory article to scripting with shelly, targeted towards those not familiar with Haskell. There is a paid version in German from Linux Magazin.
That article uses the version shelly < 1.0
which uses lazy text. shelly > 1.0
uses strict text.
More shelly packages
The shelly-extra package has some additional functionality that requires additional dependencies, currently including a convenient concurrency/futures implementation. If you are following along the above article you need to install it.
Examples
- A small deployment script
- Yesod development installer
- cabal-meta, a haskell install tool
- antigen-hs, a zsh plugin manager
Blog Posts
Testimonials
Help
Alternatives
Haskell shell scripting libarires
- HSH - A good alternative if you want to mixup usage of String and ByteString rather than just use Text.
- HsShellScript - Has extensive low-level shell capabilities.
- shell-conduit - efficient streaming via conduits. Makes some portability sacrifices by
- encouraging one to just use the shell instead of cross-platform Haskell code
- encouraging one to use a convenience function that searches the PATH at compile-time
- shell-monad - compile Haskell code down to shell script. This is a different approach from all the rest of the libraries. Writing your script is not as user-friendly as the other Haskell libraries, but it nicely solves the deployment issue.
- turtle - In some sense a redesign of Shelly designed for beginner-friendliness
HSH and HsShellScript (unlike Shelly currently) implement very efficient mechanisms for piping/redirecting in the system. turtle, like Shelly offers folding as a way to efficiently deal with a stream.
None of the alternatives to Shelly offer command tracing. For some this is an absolutely critical feature, particularly given that Haskell does not yet offer up stack traces.
Haskell file-finding supplements
- find-conduit - uses conduits, similar speed to GNU find
- FileManip - uses Lazy IO
Shelly’s finders load all files into memory. This is simpler to use if you control the filesystem structure and know the system is bounded in size. However, if the filesystem structure is unbounded it consumes unbounded memory.
Shell commands with richer input/output
Shelly does not change the nature of shell scripting (text in, text out). If you want something more revolutionary you might try these:
- Plush shell with nice GUI. Written in Haskell. Actively developed, unlike TermKit
- PowerShell is proably the best known.
- Haskell project using typed JSON
- untyped JSON
Usage
Shelly’s main goal is ease of use. There should be a primitive for every shell operation you need so you can easily build abstractions, so there are many of the usual file and environment operations.
There are 2 main entry points for running arbitrary commands: run
and cmd
.
They take a FilePath as their first argument. run
takes a [Text] as its second argument.
cmd
takes a variadic number of arguments, and they can be either Text or FilePath.
Fun Example: shows an infectious script: it uploads itself to a server and runs itself over ssh. Of course, the development machine may need to be exactly the same OS as the server.
I recommend using the boilerplate at the top of this example in your projects. This includes setting line buffering if you are dealing with text and not binary data.
{-# LANGUAGE OverloadedStrings #-}
{-# LANGUAGE ExtendedDefaultRules #-}
{-# OPTIONS_GHC -fno-warn-type-defaults #-}
import Shelly
import Data.Text as T
default (T.Text)
main = do
hSetBuffering stdout LineBuffering
shelly $ verbosely $ do
host <- run "uname" ["-n"]
if T.stripEnd host === "local-machine"
then do d <- cmd "date"
c <- escaping False $ cmd "git" "log -1 | head -1 | awk '{print $2}'"
appendfile "log/deploy.log" $ T.intercalate " - " [T.stripEnd d, c]
uploads "my-server:/remote/path/" ["deploy"]
sshPairs_ "my-server" [("cd", ["/remote/path"]), ("./deploy", [])]
else do
cmd "./script/angel"
-- same path on remote host
-- will create directories
uploads :: Text -> [Text] -> Sh ()
uploads remote locals = rsync $ ["--relative"] ++ locals ++ [remote]
rsync args = run_ "rsync" $ ["--delete", "-avz", "--no-g"] ++ args
Variadic arguments to cmd
Yes, as seen above you can write variadic functions in Haskell quite easily, you just can’t compose them as easily.
I find cmd
to be more convenient, but I often use run
and command
variants when I am building up abstractions.
Building up abstractions with cmd will require type signatures.
-- easy signature, but only allows one argument
let cabal = cmd "cabal" :: Text -> Sh Text
-- more complex signature that allows partial application of cmd
let cabal = cmd "cabal" :: Shelly.ShellCmd result => result
Escaping
By default, all commands are shell escaped.
If you want the shell to interpret special characters such as *
, just use escaping False $ do ...
Using Text and FilePath together
Shelly’s usage of system-filepath means you may need to convert between Text and FilePath sometimes. This should be infrequent though because
cmd
will convert FilePath to Text- The
</>
and<.>
combinators convert String/Text into a FilePath automatically
Manual conversion is done through toTextIgnore
or toTextWarn
.
Thread-safe working directory and relative paths
cd
does not change the process working directory (essentially a global variable), but instead changes the shelly state (which is thread safe).
All of the Shelly API takes this into account, internally shelly converts all paths to absolute paths. You can turn a relative path into an absolute with absPath
or canonic
or you can make a path relative to the Shelly working directory with relPath
.
Good error messages
Haskell’s #1 weakness for IO code is a lack of stack traces.
Shelly gives you something different: detailed logging.
In most cases this should be more useful than a stack trace.
Shelly keeps a log of API usage and saves it to a .shelly directory on failure.
If you use shellyNoDir
, the log will instead be printed to stderr.
This is in addition to the verbosely
settings that will print out commands and their output as the program is running.
Shelly’s own error messages are detailed and in some cases it will catch Haskell exceptions and re-throw them with better messages.
If you make your own primitive functions that don’t use the existing Shelly API, you can create a wrapper in the Sh monad that use trace
or tag
to log what they are doing.
You can turn tracing off (not generally recommended) by setting tracing False
.
Future plans
- improved SSH API
- more efficient piping/redirecting (issue #18)
- more efficient find functions (issue #23)
Changes
1.6.8
- added sshPairsWithOptions function
1.6.7
- flush stdout when using
echo
, not justecho_n
- fix should be able to silence stderr when using
runHandle
- expose RunFailed
1.6.6
- add prependToPath function
1.6.5
- expose MonadShControl
1.6.4.1
- add writeBinary function