[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev How to get bz2 compressed files uncompressed and rendered (
Re: lynx-dev How to get bz2 compressed files uncompressed and rendered (not
Fri, 20 Nov 1998 10:09:07 -0600 (CST)
> > It looks (after a quick look) to me that Lynx is doing internal
> > decompression of .gz files, regardless of what mailcap says. Lynx doesn't
On Fri, 20 Nov 1998, Nelson Henry Eric wrote:
> That's true now (if you use zlib), but I had very similar entries working
> when gzip had to be called externally by Lynx.
Whether you use zlib or not, the interface shouldn't have changed;
I.e. the "regardless of what mailcap says" bit should still apply.
That is, regardless of what mailcap says _about the file in its compressed
form_ (entries like "application/gzip;...". Once Lynx decides that it is
able to decompress, then what mailcap says about the type of the
underlying (uncompressed) data _does_ matter (if it applies).
> Gzip has a --no-name option
> (do not save or restore the original name and time stamp), which I think
> Lynx takes (took?) advantage of.
That is only a detail of how gzip gets called IF it gets called for
automatic gunzipping (in HTFWriter.c). It shouldn't normally make any
difference, and is only an attempt to protect from the following
theoretical case: gzipped content has a name embedded that is different
from the "normal" name, and the --no-name which is the default for
gunzipping would be overriden by a --name in a GZIP (or, for VMS,
GZIP_OPT) environment setting. In that case, the invocation of
gzip could create an uncompressed file which Lynx then wouldn't know
how to find or remove.