Re: Interest in zip archive resolver?
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...)
Re: Interest in zip archive resolver?
>I hadn.FN"t really thought of making it executable$B!D(B I think thereN"s >a >magic cookie at the beginning of a ZIP file so a hashbang might not >work if the archive were intended to be spec-compliant. No, the magic cookie (PK\005\006) is at the _end_. The central directory and file entries also have magic cookies (PK\001\002 and PK\003\004 respectively), but those don't have to be at any specific position but are pointed out as file offsets rooted in the PK\005\006 header at offset file_size-22. AFAICR it was standard practice to make self-extracting ZIP:s on MS-DOS by just cramming an MZ binary before the archive (and adjusting the offsets accordingly). It should be pretty easy to just put something at the start if creating the archive by hand like Filesystem.Zip is doing.
Interest in zip archive resolver?
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...)
Interest in zip archive resolver?
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
