Dear GAP Forum,
Dima Pasechnik asked:
1) I wonder why GAP is distributed as .zoo archive(s) rather than as
compressed tar files. (Other than historical reasons...)
The problem is that, last time we explored this, many Windows and Mac users did
not reliably have reliable tools to unpack gzipped tar archives, while we have
a single source file that provides everyone with unzoo at the cost of one extra
step. Also, since we control the unpacker, we have added a few non-standard
features, to allow, for instance, automatic correct handling of text and binary
files under Windows or MacOS. The compression is not as good as more modern
systems like gzip or bzip2, but the difference is not huge, and the people to
whom it mostly matters (modem users) probably recover some of the extra
compression in their modem hardware.
Another alternative that has been suggested to us is zip format which, we are
assured can handle text and binary nicely, and is now reliably available for
UNIX, Windows and MacOS, however it doesn't seem to offer enough advantage over
our present arrangements to justify the effort of changing at the moment.
We would like to be able to offer source and binary distributions packaged for
the popular Linux package formats (Red Hat and Debian mainly) but so far we
have not been able to find the manpower to prepare these.
Taking the liberty of re-ordering Dima's message a little, he went on to ask:
2) Windows unzoo.exe that is currently provided is de facto MSDOS
program, that converts all the filenames into 8+3 lowecase.
Anyway, it's perhaps the time to do away with 8+3 naming convention
that GAP seems to be largery adhering to (with exception of configure
shell script :-))
As it happens I raised this question this morning on the GAP developers list.
We will probably stick to a moderately restrictive convention to ensure
portability in the future, but, unless someone convinces me otherwise, I think
we can relax 8+3.
Finally, he asked:
Also, I find the LF to LFCR transition it performs on textfiles rather
unfortunate, at least this is certainly not something one wants when
The Windows binary unzoo.exe performs this translation, so that users can use
non-cygwin ports of TeX and so on. If you compile the UNIX source file
unzoo.c, under cygwin with the -DSYS_IS_UNIX compilation flag, then you should
obtain a non-translating Windows unzoo (requiring cygwin.dll). If this doesn't
work, get back to us.