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