When wget and curl know better than you do: unwanted automatic decompression
Mojca Miklavec
mojca at macports.org
Wed Jan 21 01:19:30 PST 2015
Hi,
I have troubles testing the new version of CMake. Reason?
Here's what happens on a linux box:
> curl http://www.cmake.org/files/v3.1/cmake-3.1.0.tar.gz -o cmake-3.1.0.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 5816k 100 5816k 0 0 737k 0 0:00:07 0:00:07 --:--:-- 791k
> file cmake-3.1.0.tar.gz
cmake-3.1.0.tar.gz: gzip compressed data, last modified: Mon Dec 15
21:19:37 2014, from Unix
> md5sum cmake-3.1.0.tar.gz
188eb7dc9b1b82b363bc51c0d3f1d461 cmake-3.1.0.tar.gz
> gzip -d cmake-3.1.0.tar.gz
> md5sum cmake-3.1.0.tar
6da9011024a215073c3b390e9ed6ee21 cmake-3.1.0.tar
And here's what happens on my mac:
> curl http://www.cmake.org/files/v3.1/cmake-3.1.0.tar.gz -o cmake-3.1.0.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 29.8M 100 29.8M 0 0 22.5M 0 0:00:01 0:00:01 --:--:-- 22.5M
> file cmake-3.1.0.tar.gz
cmake-3.1.0.tar.gz: POSIX tar archive
> md5 cmake-3.1.0.tar.gz
MD5 (cmake-3.1.0.tar.gz) = 6da9011024a215073c3b390e9ed6ee21
Can anyone understand why both curl and wget happily automatically
decompress the file on my Mac? This happens with both the original
version in /usr and the version shipped by MacPorts.
(At first I was questioning the weird behaviour of MacPorts that
refused to extract the file, while "tar xvzf cmake-3.1.0.tar.gz"
worked just fine. But it seems that "tar xvzf" simply ignored the fact
that the file wasn't compressed.)
Mojca
More information about the macports-dev
mailing list