Your comments

I'm hesitant to explicitly add third-party API such as those to Master Password.  First of all, I don't know what code they'd be injecting into your password manager (as they're closed source APIs), secondly, I don't recommend these services to anyone.  The syncing via these services wouldn't really be syncing either, it would be a very naive save/load feature that would erase or mess with any sites you created on your device while it was offline or on a slow network.  I might consider adding the ability to send your export file to an external application as opposed to just emailing it.  That might give you the freedom to use these services in-lieu of your email and might be a close-enough solution.
I understand that there is definitely a use case for having some reliable way of storing information about your sites.  This is, after all, why I had originally reached out to iCloud.

Sadly, iCloud has not lived up to its promises, and the headaches it causes for some as well as the way Apple's restricting its use to any applications not blessed and reviewed by Apple in addition to the bad press iCloud has received recently on the security front all add up and make it obvious that iCloud is not the solution to Master Password's sync.

Perhaps in a future version, Master Password will implement a sync that's truly secure, reliable and available to all Master Password users, on all platforms and devices, without compromise.  Until then, save your custom passwords or configurations on your multiple devices manually or use the export/import features to send your configurations across.
I'm going to keep this idea in mind and consider it for future updates.  If I can fit it in using a mostly non-obtrusive method, I shall.  Thanks for proposing it, and good point about the backward compatibility-ness.
What I meant to say is that there is zero guarantees with anything involving /bin/sh.

While those lines may work fine in YOUR /bin/sh, by no means does that mean it "works in sh", since the next guy running them with /bin/sh may well get syntax errors.  The point here being that there is no guarantees about what interpreter implements /bin/sh.  The best guarantees are provided by POSIX's minimum feature set for a shell, but there are many non-POSIX UNIX systems that have a non-POSIX /bin/sh, eg. some old bourne or even csh.

The point being, if I change my hashbang to /bin/sh, I accept that my script can run with any /bin/sh and take responsibility for it.  And I have no interest in making such a claim/statement or even researching the feasibility of it.  As far as I'm concerned, /bin/sh can die in a fire. :-)
Without the slightest intent of sounding condescending, I have no interest in writing code for a language that is undefined, undocumented and for which it is undefined what interpreter will actually end up running it.  /bin/sh isn't even guaranteed to be a POSIX sh shell.  And even if it was, POSIX sh is such a limited and broken language that I have no interest in limiting myself to it.  If you don't have bash, invoke the jar via java directly or write yourself a tiny custom wrapper for whatever shell you do have.  Better yet: compile the C CLI instead, it is vastly superior.
The default verbosity is a bit excessive.  I will fix this.