shellfire is a MIT licensed framework for building modular applications in POSIX-compliant shell script. It is designed to:-
shellfire consists of a number of github repositories, called modules. Each module contains functions or resources in a specific namespace. You create a shellfire application by making a new repository (typically on GitHub) with a skeleton structure, and then adding the modules you need. You populate a template shell script, and then just code away. It couldn't be easier. shellfire scripts work straightaway from source control. When you're ready to do a release, you can use fatten to make a standalone script, and swaddle to then deploy it to GitHub releases, pages, etc as tarballs, debs, etc.
In homage to Python, batteries are included. Here's the list of modules and namespaces:-
pushdin all shells
PATHand automatically install packages that contain them, so you can rely on
datedoing the same thing on Mac OS X as well as Linux, say
buildto drop in and make builds easy-peasy.
gitfrom shellfire applications.
Of course, this is just a start. If there's something you'd like to see, code it and submit a pull request.
Additionally, there's also
Because the shell matters, as shellshock showed us. Because the shell is powerful, but is a poorly understood programming language with too many variants and gotchas. And it needs proper constructs. And lastly, because we're fed up with having to install half-an-universe's worth of Ruby, Python and Perl to bootstrap our servers or run CI jobs*. We like Rob Landley's Aboriginal Linux. And if we want to build our own bespoke, single purpose servers, managed switches and embedded routers post-Snowden, less is more.
* And if you've had to work with some of the backwards-is-forwards sysadmins I have had to in some strange organisations, doing it all in the shell is the only way of getting it done at all.
PS: If we could have our time again with the syntax of POSIX shell script, we probably would. But we're stuck with it. The flip side is, it hasn't changed in 16 years, so today it works almost anywhere.
Well, not much yet, but, who knows? There's currently:-
We're proficient in all of them. And we've delivered some seriously hard core stuff in our time: message queue brokers that handle 1,000,000 simultaneous users in C. Postgresql network protocols in Java. Static webframeworks in Ruby. Devops automation in Python, oh, and a portfolio trading system in C#. A professional uses the language most appropriate to the problem domain. We do have beards and sandles, though.
Code is known to run well on:-
We plan to support major distributions whilst their owners support them, as long as we can access without cost to the underlying technologies. We have limited interest in supporting obscure, dying or dead commercial platforms (eg HP-UX, Tru64).
We work well on POSIX shells that support a
local keyword or alias:-
yash is not there yet but could be if there's interest. We're not going to support ksh93 as it's just too different, and zsh, great as it is an interactive shell, is a bit hit and miss. MinGW MSYS uses bash 3.1, which mostly works, but has some terrible IFS handling bugs (in particular, this affects arrays; this can be worked around, but a generic solution handicaps all other shells).