
Shellfire – A repository of namespaced, composable shell function libraries - raphcohn
https://github.com/shellfire-dev/shellfire
======
pherocity_
I love the idea, I've also been frustrated, and there has been chicken and egg
problems which this may help with. That said, the quote:

> "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 _"

If this takes off, some will use it some won't, and we'll be stuck installing
a "half-an-universe's worth of Ruby, Python, Perl, and Shellfire scripts to
bootstrap our servers or run CI jobs_"

~~~
raphcohn
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).

~~~
mietek
So, this is pretty cool. I am in particular impressed how thorough your curl
wrapper is. Mine is pretty basic in comparison:

[https://github.com/mietek/bashmenot/blob/master/src/curl.sh](https://github.com/mietek/bashmenot/blob/master/src/curl.sh)

~~~
raphcohn
Thank you. There's lots of good stuff in bashmenot. Is there anything you
think you'd like to add to shellfire to make it even better?

------
norswap
What I'm worried about this is that it builds on shell precisely. So to debug
it / understand how it behaves, you need to understand shell (I suppose bash
for most people) + shellfire. bash is already full of pitfalls, I'm not very
enthused of adding a layer on top. While it certainly helps when you know what
you're doing / it works; it obscures the cause of some already obscure
behaviour even further.

I also don't like the "framework" approach. I actually thought this would be
actual "shell functions" to do all kinds of common shell tasks; a copy-paste
library of sorts. I was actually pretty excited about that as it is something
I see myself using on a regular basis.

But don't let my negativity bring anybody down, I'm sure it can be useful; and
if it's useful for you, just use it and be happy.

~~~
raphcohn
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.

------
Sir_Cmpwn
This is pretty cool. It faciliates the use of what I've seen as a number of
sore omissions from bash. I dislike the "why aren't you using a real language"
mentality - if we can make bash better, why not do it?

~~~
andreasvc
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.

~~~
Sir_Cmpwn
I wouldn't suggest writing user-facing shell scripts, and bugs (even big ones)
happen with other languages all the time. I don't want to see large pieces of
software written entirely in bash, but scripting where it's useful is fine
with me.

------
adrusi
I love shell scripts because they let you distribute zero-setup portable
programs without dependencies. But if you're already going to be depending on
shellfire, why not instead depend on a VM for a more appropriate language?

I think posix shell is quite a beautiful language, and I enjoy hacking
together a medium size application with it just because it's fun, but it has a
lot of disadvantages relative to a more modern scripting language. If you use
perl/python/ruby/javascript/lua/lisp instead, your application will perform
better, be easier to maintain and be able to run on windows without cygwin.

I get the impression that this project is trying to advertise itself for
making real applications, but I don't think that's realistic. As a toy,
though, it's really cool and I'll probably play around with it at least a
little.

~~~
pyre
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](https://github.com/shellfire-
dev/fatten)

~~~
raphcohn
Yep, that's _exactly_ why fatten exists. There's also swaddle[1], which
complements fatten to make apt and yum repos with deb packages and rpms.

[1]
[https://github.com/raphaelcohn/swaddle](https://github.com/raphaelcohn/swaddle)

------
_paulc
I'm a big fan of removing dependencies and very partial to distributing single
dependency free executables, but don't you just need to install all the
shellfire dependencies instead of Python/Ruby etc. Appreciate that you can
'fatten' apps but this is true for the other languages too (pyinstaller etc.).

~~~
raphcohn
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.

------
0xCMP
It looks cool, but pretty complicated (as shell script always seems to be in
real application). I'll have to come back and see what I can come up with or
replace using this though.

Good work (as far as I can see)!

~~~
raphcohn
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](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?

