Hello all,
I’ve been going through some of my long ignored feature branches and found a few that might have promising code.
Is there any interest in being able to specify (include/program/module) paths in terms of zip archives? At one point I wanted to be able to provide an entire application as a single file, and wrote support for various paths inside of zip files. The code I wrote is about 7 years old, but it was/is used and I’d be happy to fix it up if no one has major objections.
The code in question provides support for including zip files as part of paths for -I, -P and -M:
pike -M /path/to/some.zip
or
pike -M /path/to/some.zip/folder
As well as the idea of a properly formatted archive with well know directories for modules, includes and programs:
pike -A /path/to/some.zip
where some.zip looks like:
include/* modules/*
And implicitly sets -I, -M and -P to include/, modules and / respectively.
Any thoughts, opinions, suggestions?
Bill
Hi Bill.
This sounds like the custom master I did some decades ago which used Filesystem.Tar in master_read_file() and master_file_stat(). One nice thing with tar files is that they start with the filename of the first file, which can be anything, so you can actually put a hashbang there and make the whole thing executable.
Come to think of it, zip files have all their metadata at the end, so I guess you could do the same with zips if you add a little effort? It would be sweet to have a "pike -x zipackage" which automatically created a stand-alone archive with a working hashbang!
(For W*ndows you'd probably have to pick a filename which ends with .somemagicletters for the archive to be exectutable as an application...)
After a bit of research I realized that I'd already committed the basic support for having search paths in ZIPs back in 2014: If an added module or include path is actually a file and not a directory, a Filesystem.ZIP for it is created and a filesystem handler is added.
What remains, then, is a command argument to specify a path to a ZIP and then implicitly add module, include and program paths. Also, probably an understanding of what those should be (perhaps a case insensitive lookup of modules, includes, etc?). Any thoughts on that?
Thus if the option were, for example [-A archive.zip [... -A archiveN.zip]]
pike -A archive.zip
Yields the following calls (should the respective paths be present):
add_include_path("/path/to/archive.zip/include"); add_include_path("/path/to/archive.zip/modules"); add_program_path("/path/to/archive.zip");
Similarly, it might be nice to be able to specify a program to run automatically, ala java -jar... I think such an option would probably need to be mutually exclusive vis a vis the option above. There would probably also need to be a mechanism to specify what the program to run would be. If you had that framework in place, a self executing file would practically create itself (except perhaps on Windows, of course).
Any thoughts? Is my thinking completely off?
Bill
On 2020-04-17 12:59, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Hi Bill.
This sounds like the custom master I did some decades ago which used Filesystem.Tar in master_read_file() and master_file_stat(). One nice thing with tar files is that they start with the filename of the first file, which can be anything, so you can actually put a hashbang there and make the whole thing executable.
Come to think of it, zip files have all their metadata at the end, so I guess you could do the same with zips if you add a little effort? It would be sweet to have a "pike -x zipackage" which automatically created a stand-alone archive with a working hashbang!
(For W*ndows you'd probably have to pick a filename which ends with .somemagicletters for the archive to be exectutable as an application...)
pike-devel@lists.lysator.liu.se
-
H William Welliver -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum -
william＠welliver.org