[ESS] ess-17.11-tgz is not compressed
Martin Maechler
m@ech|er @end|ng |rom @t@t@m@th@ethz@ch
Thu Dec 7 17:42:35 CET 2017
>>>>> Martin Maechler <maechler using stat.math.ethz.ch>
>>>>> on Thu, 7 Dec 2017 17:37:23 +0100 writes:
>>>>> Neil Shephard <nshephard using gmail.com>
>>>>> on Tue, 5 Dec 2017 08:18:08 +0000 writes:
>> Hi, I've only just caught up on the update to ess-17.11
>> and went to install it using the Gentoo Linux package
>> management system portage.
>> It complained that the ess-17.11.tgz was not a compressed
>> archive and this appears to be true, its just a plain
>> tar-ball.
> well, I'm managing the ess.r-project.org server and I have
> actually mounted the file system where ess-17.11.tgz lives
> and 'ls -l' and 'file' say
> ls -l ess-17.11.tgz -rw-r--r--. 1 maechler sfsstaff
> 3275703 Nov 13 15:13 ess-17.11.tgz
> file ess-17.11.tgz ess-17.11.tgz: gzip compressed data,
> last modified: Mon Nov 13 14:13:29 2017, from Unix
> (and read on)
>> This means that when portage trys to unpack it based on
>> the file extension '.tgz' it tries to uncompress it,
>> which fails.
>> For now I've change the ebuild (the scripts which install
>> programmes under Gentoo/Linux) to use the ess-17.11.zip
>> but thought this worth reporting. I include below
>> downloading the ess-17.11.tgz and attempting to
>> unzip/uncompress manually, what finally worked was
>> renaming to ess-17.11.tar and untar the archive.
>> Details of this are also on Gentoo Buzilla at
>> https://bugs.gentoo.org/639752
>> Regards,
>> Neil
> Now look closely at the output of wget -- which I can
> reproduce in my (Fedora 26) Linux :
>> ~/tmp/ess $ wget
>> http://ess.r-project.org/downloads/ess/ess-17.11.tgz
>> --2017-12-05 08:12:09--
>> http://ess.r-project.org/downloads/ess/ess-17.11.tgz
>> Resolving ess.r-project.org... 129.132.119.195 Connecting
>> to ess.r-project.org|129.132.119.195|:80... connected.
>> HTTP request sent, awaiting response... 200 OK Length:
>> 3275703 (3.1M) [application/x-tar]
> ^^^^^^^^^^^^^^
>> Saving to: ‘ess-17.11.tgz’
>>
>> ess-17.11.tgz
>> 100%[===========================================================================================>]
>> 3.12M 6.30MB/s in 0.5s
>>
>> 2017-12-05 08:12:09 (6.30 MB/s) - ‘ess-17.11.tgz’ saved
>> [8898560]
> ^^^^^^^^
> so indeed wget seems to do __silly!__ behave a bit
> magically nowadays ... -- at least being honest about it:
> It gets a *.tgz of size 3275703 bytes (~ 3.1 M) and
> internally uses gunzip absolutely with*OUT* saying so, but
> then honestly reports that the result is of size 8898560
> bytes
> I'm appalled.
> Note one thing though: For 2 year or so, 'tar' has become
> smart enough to "see" if it needs to uncompress or not; so
> for practical purposes, you nowadays can use
> tar xf <file>
> and it will do the right thing if the file is compressed
> or not.
Well, not quite: If the file ends in *.tgz it tries
automatically to use gunzip on it and fails...
so it seems the manual 'mv ...tgz ...tar' seems needed.
Ok, now having skimmed the result of 'wget --help', I see
(among HTTP options) :
--compression=TYPE choose compression, one of auto, gzip and none
and indeed some silly people made 'auto' the default *and*
forgot to implement a renaming of *.tgz --> *.tar in the case of
auto compression.
The solution for (tested): Use wget --compression=none :
$ wget --compression=none http://ess.r-project.org/downloads/ess/ess-17.11.tgz
--2017-12-07 17:40:02-- http://ess.r-project.org/downloads/ess/ess-17.11.tgz
Resolving ess.r-project.org (ess.r-project.org)... 129.132.119.195
Connecting to ess.r-project.org (ess.r-project.org)|129.132.119.195|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3275703 (3.1M) [application/x-tar]
Saving to: 'ess-17.11.tgz.1'
ess-17.11.tgz.1 100%[==========================>] 3.12M --.-KB/s in 0.04s
2017-12-07 17:40:02 (81.1 MB/s) - 'ess-17.11.tgz.1' saved [3275703/3275703]
--
Martin Maechler ETH Zurich
More information about the ESS-help
mailing list