discussion: target platforms and test coverage

[realtime-neil]

Consider the following questions:

• What is the target platform for makeself?
• How should makeself be tested for proper function on the target platforms?
• Which (if any) assets, fixtures, and/or harnesses are required to test makeself?

Pursuant to earlier conversations...

• script & args -> startup command, fix #171 #177
• Include empty dirs in archive -- Fix #175 #176

...between @megastep , @bracketttc , and myself, I get the distinct impression that there is a need to specify the functional requirements on makeself. The README.md proudly (and rightfully) reports the following astounding accomplishments:

As of version 2.1, Makeself has been rewritten and tested on the following platforms:
Linux (all distributions)
Sun Solaris (8 and above)
HP-UX (tested on 11.0 and 11i on HPPA RISC)
SCO OpenUnix and OpenServer
IBM AIX 5.1L
macOS (Darwin)
SGI IRIX 6.5
FreeBSD
UnicOS / Cray
Cygwin (Windows)

I want more; i.e., a CI test suite that proves the aforementioned assertions at will, for any commit within the makeself repository.

To assemble such a test suite, we require at least some of the following:

• an enumeration of supported Operating Systems
• an enumeration of supported shells (possibly conditional on the supported Operating System)
• a mechanism whereby a given supported target can be mocked on a "modern platform"

I'll go first:

• I think that we should target a circa 1987 Bourne Shell.
• I think we should use containers to fake an environment for testing.

What say others?

[realtime-neil]

Here's something interesting: https://www.in-ulm.de/~mascheck/bourne/

[bracketttc]

That sounds fantastic.

Once a firm set of requirements is established, we can set up testing against them and ensure that new features work within those bounds (or are optional and disable themselves safely/automatically on platforms that do not support them).

An example of a thing that already exists in the scripting that is a bash-ism is type. But its use is fairly safe because it comes at the end of a series of standard commands that also look to identify an executable or built-in shell function.

makeself/makeself.sh

Line 643 in 50fb888

SHA_PATH=`exec <&- 2>&-; which shasum || command -v shasum || type shasum`

This pattern shows up in at least one other place, and there is an instance of type being used without exhausting the standard commands first. Perhaps this pattern should be abstracted into a shell function and we should standardize on that where makeself or a makeself archive needs to verify that a command is present. I'll open an issue, and probably a PR tonight.