It appears that the offset calculation is not always correct. The approach
fails in an obvious way if the first line of an archive consists entirely of
printable characters. Unfortunately, this can indeed happen, an example
is the latest GoogleEarthLinux.bin (version 4.0.2414). Please consider the
patch below for a different method to determine the offset.
How-To-Repeat: fetch http://dl.google.com/earth/GE4/GoogleEarthLinux.bin
Over to maintainer
jylefort 2006-11-06 20:08:48 UTC
FreeBSD ports repository
- Fix archive offset calculation (problem reported in )
- Various code cleanups
Submitted by: Frank W. Josellis <email@example.com>
Revision Changes Path
1.5 +12 -12 ports/archivers/unmakeself/Makefile
1.3 +126 -83 ports/archivers/unmakeself/files/unmakeself.c
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "email@example.com"
Good catch. However I do not want to execute the script (I don't think the
command line options are consistent across versions), so I now check for
gzip/bzip2 magic numbers, and if it does not work I fallback to the
previous "printable" method. Thanks for the patch anyway.
Thanks for your prompt action, it's ok now with RELENG_6. But on RELENG_5
(and earlier) we're still in trouble: memmem() is not adopted here.
I remember to have encountered this problem earlier with GNUish software,
and I had to introduce memmem() explicitly to make it work.
On Tue, 7 Nov 2006 14:58:14 +0100 (CET)
"Frank W. Josellis" <firstname.lastname@example.org> wrote:
> Thanks for your prompt action, it's ok now with RELENG_6. But on RELENG_5
> (and earlier) we're still in trouble: memmem() is not adopted here.
> I remember to have encountered this problem earlier with GNUish software,
> and I had to introduce memmem() explicitly to make it work.