On 07/07/2016 12:14 AM, Marc Nieper-Wißkirchen wrote:>     In some environments any requirement for an executable as single file may be awkward.

>     FWIW: I was surprised to find out you can concatenate a shell script with the .jar
>     (Java Archive) file, and have the shell script call something like 'exec java -jar $0'.
>     I.e. the java command can skip the shell-script preamble when looking for the jar contents.
>     So that may be a possible approach for Java and other JVM-based implementations.
>
> This is good to know, so Kawa should be able to implement this SRFI!
>Is this the official way how JVM-based programs are turned into proper executable files?

I don't believe so, no.  I haven't see any official documentation suggesting so.

The Java platform uses .jar files as a portable distribution mechanism.
Scripts and executable would be less portable.

It is common for a "binary release" to extract into a directory structure containing
at least one or more jar files, *plus* a shell script and a .bat file.
This is what the latest (unreleased) Kawa does.

On 07/07/2016 04:09 AM, John Cowan wrote:

> Indeed.  Jar files are in zip format, and the directory in a zip-format
> file is at the end.  Only portions of the file referenced by the directory
> will be processed by any unzipper, so arbitrary content can be prepended
> to the file without disturbing its validity as a zip file.

This assumes that libraries for reading zip file entries can read "relatively".
(The zip specification says the central directory contains for each
entry a "relative offset of local header", but seems to say it is relative
from the *start* of the "first disk", which doesn't help.)

Still, tools I've tried do seem to handle such hybrid script+zip files,
so it does seem to be a standard (if poorly-documented) feature.

> In MS-DOS days it used to be popular to put a small self-unzipper there,
> so that people without unzip could just run the zipfile (if it had an
> extension of .EXE) and it would extract its own contents.  If you were
> not on MS-DOS, the self-unzipper wouldn't work, but you could still use
> an unzip tool.
>
> The program unzipsfx, distributed along with unzip, can still do this,
> but can of course only extract when run on the type of system it was
> compiled for.  The whole idea is not very popular any more.

... partly due to it being a popular mechanism for running malware.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/