Mail Archives: djgpp/2019/02/03/02:14:24
This is a port of GNU gzip 1.10 to MSDOS/DJGPP.
gzip (GNU zip) is a compression utility designed to be a replacement
for 'compress'. Its main advantages over compress are much better
compression and freedom from patented algorithms.
DJGPP specific changes.
=======================
This port is based on the previous ports gzip13N[bds].zip. This means,
that all the DJGPP specific funtionality introduced with those ports will
also be available in this new port. No new DJGPP specific functionality
has been added.
This is a recompilation of all new features introduced with previous ports
and also available in this port:
- Gzip now fully supports long file names on those platforms where DJGPP
can access them. This means, for example, that compressing `foo.tar' on
Windows 9X will produce `foo.tar.gz', not `foo.tgz'.
For backward compatibility, Gzip knows about butchered DOS-style
extensions of compressed files even when long file names are supported.
For example, if you have `foo.tgz' and you type "gunzip foo.tar", Gzip
will find the file even on Windows 9X. Short variants of compressed
extensions are checked *after* the long ones, so Gzip will try to find
`foo.tar.gz' before `foo.tgz'.
Long file name support is checked for each file submitted to Gzip, so
it will treat each one of them in accordance with the properties of the
file system where that file resides. In other words, you can compress
files that reside on DOS and Windows file systems within a single Gzip
command.
- Gzip will no longer appear to hang when its input comes from the console
device. Previous ports would hang when the user typed "gzip -f [Enter]".
This port allows you to either interrupt the program with Ctrl-C (if you
typed that command by mistake), or type in the input and end it with a ^Z
(if you really mean to compress the text you type from the keyboard).
This is done by avoiding to switch the console device to binary mode,
so any console reads are now done in text mode.
- The default compressed file extension is now `.gz', not `z'. This is
so that compressed file names on Windows 9X would have the usual `.gz'
extension, but it also means that `foo.cc' will now be compressed into
`foo.cgz' when long file names are not supported. Use the -N option to
`gunzip' to restore the original name, if the original file name had
more than one character in the extension.
- When restoring original file names, `gunzip' now converts all characters
that are not allowed in DOS/Windows file names to similar but valid
characters, and changes the file name if it is reserved by a DOS device
driver (like `aux.text' or `prn.tar') by prepending an underscore to it.
- In previous ports, uncompressing files with certain names on Windows 9X
when numeric tails are disabled would trigger false warnings about file
name truncation. This is now fixed.
- Truncation of long file names on plain DOS is somewhat smarter now:
`gunzip' treats several additional characters (like `-' and `_') as
part delimiters.
- Shell scripts `zmore', `zgrep' and others now work on DOS and
Windows, and are distributed with the binary distribution, as are all
the man pages supplied with the official GNU sources.
- Shell script `zdiff' does not work on DOS and Windows, because it uses
subshells to invoke gzip and to generate the error code (return value)
of the command. Unfortunatly this does not work with the port of bash.
All the changes done to the original distribution are documented in the
diffs file and located together with all the files needed to configure
the package (config.bat, config.sed, config.site, etc.) in the /djgpp
directory.
To build this port and run the test suite you will need LFN support.
The sources have been configured to be build in the /_build directory.
If for some reason it does not work for you, delete its contents and
configure from scratch again.
For further information about GNU gzip please read the info docs
and NEWS file.
Here is an extract of the NEWS file showing the user visible changes
from the last port (GNU gzip 1.8) to this one:
-------------------------------------------------------------------------------
* Noteworthy changes in release 1.10 (2018-12-29) [stable]
** Changes in behavior
Compressed gzip output no longer contains the current time as a
timestamp when the input is not a regular file. Instead, the output
contains a null (zero) timestamp. This makes gzip's behavior more
reproducible when used as part of a pipeline. (As a reminder, even
regular files will use null timestamps after the year 2106, due to a
limitation in the gzip format.)
** Bug fixes
A use of uninitialized memory on some malformed inputs has been fixed.
[bug present since the beginning]
A few theoretical race conditions in signal handers have been fixed.
These bugs most likely do not happen on practical platforms.
[bugs present since the beginning]
* Noteworthy changes in release 1.9 (2018-01-07) [stable]
** Bug fixes
gzip -d -S SUFFIX file.SUFFIX would fail for any upper-case byte in SUFFIX.
E.g., before, this command would fail:
$ :|gzip > kT && gzip -d -S T kT
gzip: kT: unknown suffix -- ignored
[bug present since the beginning]
When decompressing data in 'pack' format, gzip no longer mishandles
leading zeros in the end-of-block code. [bug introduced in gzip-1.6]
When converting from system-dependent time_t format to the 32-bit
unsigned MTIME format used in gzip files, if a timestamp does not
fit gzip now substitutes zero instead of the timestamp's low-order
32 bits, as per Internet RFC 1952. When converting from MTIME to
time_t format, if a timestamp does not fit gzip now warns and
substitutes the nearest in-range value instead of crashing or
silently substituting an implementation-defined value (typically,
the timestamp's low-order bits). This affects timestamps before
1970 and after 2106, and timestamps after 2038 on platforms with
32-bit signed time_t. [bug present since the beginning]
Commands implemented via shell scripts are now more consistent about
failure status. For example, 'gunzip --help >/dev/full' now
consistently exits with status 1 (error), instead of with status 2
(warning) on some platforms. [bug present since the beginning]
Support for VMS and Amiga has been removed. It was not working anyway,
and it reportedly caused file name glitches on MS-Windowsish platforms.
-------------------------------------------------------------------------------
The port consists of the usual three packages that have been produced
using djdev205 and can be downloaded from ftp.delorie.com and mirrors
as (time stamp 2019-01-08):
gzip 1.10 binaries, info and man format documentation:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gzip110b.zip
gzip 1.10 dvi, html, pdf and ps format documentation:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gzip110d.zip
gzip 1.10 source:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gzip110s.zip
Send gzip specific bug reports to <bug-gzip AT gnu DOT org>.
Send suggestions and bug reports concerning the DJGPP port
to comp.os.msdos.djgpp or <djgpp AT delorie DOT com>.
If you are not sure if the failure is really a gzip failure
or a djgpp specific failure, report it here and *not* to
<bug-gzip AT gnu DOT org>.
Enjoy.
Guerrero, Juan Manuel <juan DOT guerrero AT gmx DOT de>
- Raw text -