Skip to content
Shell: A neat remote shell-script runner, with out the box support for code/script sharing sources such as GitHub, Gist, Pastie, etc.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.



Remotely stored shell scripts executable locally.

The Problem

There are plenty of tools out there that makes it more or less straightforward to run scripts on a remote machine. What’s funny though is that many people tend to spend more time on trying to get libraries to work on the local machine, because this is the place where the development and testing takes place. The reason for this is that compiling 3rd party libraries can be a real pain when it comes to different hardware architecture, OSs, OS versions, etc. No, package managers (such as port, apt-get, etc.) is not solving this all the way – sometimes not at all. What I usually do to in such cases is to find and copy-paste shell script “setup recipes” from docs/forums/blogs that – well, usually – works for a specific setup. This is not very scalable though, and actually a waste in many senses:

Key reasons:

  • Old-school sharing => Setup recipes that works are spread thorough blogs/forums mostly, there’s no single resource if you not having your own repository and cloning the scripts manually.
  • No versioning => Same ’ol scripts might stop being “the way of doing it” because of library changes
  • New machine => Same solution probably not works now, i.e. back to finding new setup recipes
  • Conventions?

A Solution: Shelly

Shelly solves this by letting you run scripts – on your local machine – from a remote server like local shell commands almost. You don’t need to get paid storage for this; Shelly can load scripts from code hosts solutions like GitHub, Gist, Pastie, etc., which is usually used for purposes of sharing code/snippets with each other anyway.

Key concepts:

  • Run remotely stored setup scripts/recipes on local machine directly – without downloading/copying stuff manually.
  • No new DSL, just a command that runs a shell script resource (Note: No Windows scripting support).
  • Easy to share setup recipes (shell scripts) – shell script platform?
  • Easy on the eye and memory; easy to learn how to use and remember how to access a script.
  • Out-of-the-box supported script sources: GitHub repos, Gist, Pastie, Pastebin, Raw/URL.
  • Local script aliases for personalization – optional though.


$ sudo gem install grimen-shelly


$ sudo gem install activesupport
$ sudo gem install octopi

Basic Usage

Run GitHub script source:

$ shelly run github:grimen/my_shell_scripts/

Run Gist script source:

$ shelly run gist:112090

Run Pastie script source:

$ shelly run pastie:478898

Run Pastebin script source:

$ shelly run pastebin:23233

Run custom script source:

$ shelly run

Example Output:

$ shelly run pastie:478898
[shelly]: Script source type: PASTIE
[shelly]: Script source URL:
[shelly]: Fetching script...DONE
[shelly]: Executing script...
============================================================== SCRIPT =======
Quack, quack!
Quack, quack!
[shelly]: Cleaning up...DONE
[shelly]: END

Advanced Usage


Add repository:

$ shelly add repo github:grimen/my_shell_scripts

Note: The files within this repo is now accessible. Example-file:


$ shelly run


Add alias:

$ shelly add alias quack:gist/112090


$ shelly run quack

NOTE: Security Implications

There are obvious security implications with running shell scripts from remote locations, but the same applies to scripts downloaded manually – which is why Shelly got born in the first place. As long as you know what you doing, security should not be a big issue really. You’ll need root access (sudo) to run a script no matter if it’s required by the script or not.

Bugs & Features

Shelly is in a sort of conceptual stage, so a lot of improvements can be made. If you got any suggestions, issues, or find any vicious bugs, just file an issue or notify me.


Copyright © 2009 Jonas Grimfelt, released under the MIT-license.

Something went wrong with that request. Please try again.