One thing I prefer about progress is that the default config includes an ETA, which is generally the thing I care most about. It's interface is also a little nicer. It's really nice to have an estimate on when a script might complete, so I know if I have to optimize it or if I can just leave it running for a while.
There is still plenty of scripts that I write that are geared towards development workflow. I haven't had issues on setting up these tools on Debian servers, Ruby is usually preinstalled and all you need is bundler to get what you need.
In my scripting experience I tend to gravitate towards two solutions. If my script is fairly small, e.i. in a single file, with no much complexity I tend to use Ruby standard library optparse. However, if my needs get a bit more complex and I need, for example, subcommands I use thor. Thor gives me a better way to structure my application logic. These two solutions so far have covered all my needs.
Other solutions that I've played in the past are:
* main - very sweet DSL (https://github.com/ahoward/main)
* clamp - (https://github.com/mdub/clamp)
* slop - (https://github.com/leejarvis/slop)
* gli - for Git-like interfaces (https://github.com/davetron5000/gli)
My recommendation before using other libraries would be to really give optparse a good spin so that you can figure out why the other options are more suitable.
There are lots more options here: http://www.awesomecommandlineapps.com/gems.html
I've used the Python version with great success.
Consider netcat. You read the man page, and try to do something following its advice. Often enough, it just doesn't work. Because it's trying to cover a range of unrelated usages through a single entrypoint.
It's easy to set up multiple exes cleanly. Have a non-executable module that contains the functions that your application requires (e.g. call it lib.rb). For each distinct usage, create a separate executable script that imports lib.rb, extracts a, b and c from the for just that usage and then call lib.usage(a, b, c).
Users will find this easy to discover. You will find it easy to maintain, even compared to dedicated parsing DSLs.
We don't special-case functions to do multiple things based on complex argument cases. We just create well-defined functions. We should think of executables in the same terms.
If args are in a structure that can be peeked and shifted, you're in a good place for context sensitive options. It's just a lexer.
My tools tend towards this syntax:
cmd [<global opt>...] subcommand [<local opt>...]
click ( http://click.pocoo.org/6/ ) has a lot of this stuff in one package, but not everything, eg. composable command lines, progress bars, spinners, prompts, bash completion, colors, paging, launching common applications ($EDITOR) 'n stuff like that.
pyinvoke has a somewhat different focus, but also quite some stuff similar to this.
clint ( https://github.com/kennethreitz/clint ) is another bag of tools, with things like awesome tables, colors, progress bars, ...
i personally like plumbum, but its definitely not the same.
Rake is seriously underrated I believe. It allows for dependencies and rules, figures out which steps are up-to-date and skips those, allows easy parallelisation etc. Much like make, but with the familiar and sane (ye beautiful) syntax of ruby and its extensive ecosystem.
* A ruby script that deploys our application
* A ruby script that cleans up the repository after deploy
* A terminal-based git script that runs through all modified files, shows me the diff and allows me to either [c]ommit, [d]iscard changes, [s]kip or [q] before I commit.
That last script is a prime candidate to use those tty-* gems.
The whole idea of exposing end users to your apps's depencies and compilation is a broken user hostile model. The potential rabbit hole of versions incompatibilities and mismatches is a time sink that cannot be justified.
Go is by far the simplest hassle free deploy followed by PHP and Python. For a unix command line tool that seeks a userbase beyond Ruby users Go or Python would be the most user friendly choice.