[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

[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

[raphcohn]

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