[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.