Shellfire – A repository of namespaced, composable shell function libraries

Perhaps - I hadn't yet even thought of dreaming the similitude of it taking off. Thanks (;-). But shellfire wouldn't be as invasive. Each shellfire script stands alone, a bit like a statically-compiled C executable. Of course, there are still call outs to third-party binaries - but that ordinarily shouldn't be much more than busybox or coreutils, grep, awk and sed, with may be curl. And one can, with shellfire snippets, even embed binaries in the shell script... although whether that's wise is another discussion.

The proof in the pudding will be trying to make libertine linux use it - a not even started project of mine to build a minimal, net-bootable linux with an immutable file system (upgrade == reboot a new image).

Yeah, I'm ambivalent about this. (For some background, I used to hate Perl until I had to write some non-trivial shell scripts, then I realized Perl was a godsend compared to shell).

We've long been at the point where you can expect Perl and Python to be installed (Perl is required by the Debian's base tools, and Python by Redhat's).

You may not have the libraries you need at the version you need, and it's a shame that neither system has a convenient way to address that (Python virtualenv remains a hacky solution IMHO).

I was initially enthused by Shellfire's offering but, come to think of it, all it's doing is bringing SH scripting to some level with Perl or Python... but, as you point out, we have those already.

Thank you. It's almost impossible to have a set of 'shell functions' that are entirely independent of one another, once you move beyond a few special cases. That said, this is as near to copy and paste as you can get - it's Git based, and the idea is you just add groups of functions as git submodules. You can test and deploy as you go, and then, when you're ready, fatten the script and release it.

The shell needs to be understood. There's no doubt it's an old looking-language to most people, but that's why we should treat it with the same discipline as anything else. I'd agree that the shell can be obscure. Wherever possible, shellfire tries to make things explicit, not obscure through good naming; hence the reams of functions on core/variable to do simple things, eg core_variable_startsWith rather than having to figure the weird looking ${var?/:} syntax.

> "I dislike the "why aren't you using a real language" mentality - if we can make bash better, why not do it?"

Because missing something is only one way that something can suck. Not everything can be fixed through additive processes.

Why not? Because building on a solid foundation makes for more reliable and robust programs. Things like Shellshock and the Valve bash bug that wiped out all your files demonstrate that the shell scripting languages have fundamental design flaws which make bugs more likely than in other languages.

In a more controlled environment where you are writing shell scripts all of the time, it seems like this could be something useful. For example, you could distribute it with your "dotfiles" to use in your .bashrc / .zshrc files. Or you could make sure it's installed on all of your Linux/*BSD servers.

It's obviously not so great for distributing around to random places where it probably won't be installed.

Edit: Right in the README is this:

> fatten[1], to make standalone shell scripts

[1] https://github.com/shellfire-dev/fatten

shell script and a modern language like Python or Ruby have different use cases. Both have expressiveness, and power, and all, including the shell, very different applicability.

This project is far from a toy; there's a complete MQTT client written in it, bish-bosh[1], and swaddle (see comment below). I wouldn't build a webserver in it, but I would build command line wrappers of all those REST APIs out there so I don't have to install gems and eggs and whatever else to just get stuff done. shellfire is minimally dependent.

shellfire exists because installing Ruby and Python and all their dependencies is simply not an option for minimal bare metal servers and routers. Because there are far too many 'toy' shell scripts out there that aren't robust. Because the shell is the glue we need for out big ticket applications. Because I really loathe having to depend a VM configured and setup and snapshotted.

Performance is not a goal, not should it be for any scripting language. If you need performance, write in C or perhaps Java, although V8 is getting closer all the time.

And there is not dependency. shellfire deliberately discourages the model of 'install framework in /usr/lib'. It just doesn't work. But it does support working nicely with git-based dependencies as you develop; you can even deploy as nothing more than a git export, if you so choose.

[1] https://github.com/raphaelcohn/bish-bosh

No, it's not like Python/Ruby/etc dependencies. You use your own git; dependencies are submodules in your git repo. shellfire deliberately is not designed to be installed in `/usr/lib` or wherever. In this sense, it's more like Go. Going down the git route gives fine-grained control over which dependency versions one uses.

This makes development completely independent of the `/usr`, etc of the machine your own. If you clone your repo from your laptop to someone else's desktop, no need to to install deps, no need even for a working network env - valuable if you're in one of those places that breaks Ruby because they uses a Windows proxy (eg most UK Gov setups).

You don't have to fatten; you can just deploy by exporting your git repo. That sort of route would be perfectly acceptable for most enterprise work. Still no need to install deps, as everything is relatively-pathed.

Thank you, that's appreciated. I want it to not be complicated in use - but like anything new, there's always that wall of initial confusion. It's early days for all of it, and this is taking a very different approach with the shell: it treats it like a proper language. Arguably, one that needs much more discipline than first appears.

Everyone has a different learning style - perhaps the tutorial will help? Or just looking at a real use case - try bish-bosh at https://github.com/raphaelcohn/bish-bosh. Let me know if there's a better way of explaining it.

If there's enough folks interested, maybe we could run an interactive tutorial or IRC session?