0
Declined

Improve script for java cli version

Michael Breuer 3 years ago • updated by Maarten Billemont 3 years ago 4
Hey,
your mpw-script in the java-cli release of your app makes use of bash shell, which is not on every platform available/installed.  in unix/linux it's common practice to use sh for such scripts to get the most portable solution. Because your script doesn't make heavy use of bash-only features it should be possible to make a more portable version using sh.
Under review
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.
I would never use sh in interactive sessions. The reason's have you already mentioned. And you're absolutely right. But it's existence is somewhat guaranteed and therefore suitable for such scripts.

And without the slightest intent of sounding condescending, these three lines of code in your bash script work even in sh ;-)
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. :-)