bug#8609: $GZIP doesn't mean what you think it means.

[Alan Curry]

Let me show you what happens if I try to clone coreutils from git and compile
in the most straightforward way possible:

% git clone git://git.sv.gnu.org/coreutils
Cloning into coreutils...
remote: Counting objects: 151287, done.
remote: Compressing objects: 100% (37539/37539), done.
remote: Total 151287 (delta 113807), reused 150796 (delta 113449)
Receiving objects: 100% (151287/151287), 26.95 MiB | 767 KiB/s, done.
Resolving deltas: 100% (113807/113807), done.
Script started on Tue May  3 00:40:20 2011
% cd coreutils
% ./bootstrap
./bootstrap: Error: '-9' not found

./bootstrap: See README-prereq for how to get the prerequisite programs
%

On seeing that the first time, I immediately knew what happened and worked
around it... then quickly got into trouble trying to git bisect something and
forgot about it. Now I've repeated the process (including getting into
trouble with git bisect but that's for later) and decided that this bug,
though easily worked around, deserves to be reported.

bootstrap wrongly assumes that if there's a GZIP environment variable, it
must contain the pathanme of a gzip program. gzip is a tool we use all the
time, so I would have hoped that GNU developers would have read its
documentation, but apparently not. The GZIP environment variable is used to
pass default options, hence the "GZIP=-9" which has been in my environment
for a long time.

If you even tried putting "GZIP=/bin/gzip" in the environment, you'd find
that gzip no longer works properly, because it acts as if an extra
"/bin/gzip" was given on the command line... and if you did it as root,
congratulations, you just gzipped your gzip program.

Surely gzip has the authority to define the semantics of the GZIP environment
variable, and bootstrap should not be making the unwarranted (and obviously
untested obviously) assumption that it means something different.

I assume this bug resulted from an over-generalization of the pattern
CC=gcc, MAKE=gmake, ...

In the environment of my current login shell, there are 10 environment
variables with names that (after tr A-Z a-z) are also programs in my PATH.
Of those 10, 3 follow the $GZIP pattern where the value of the environment
variable is a list of options for the command. Another 3 fit the pattern
"COMMAND=/path/to/implementation/of/command".

Neither pattern is a reliable predictor of the semantics of an arbitrary
environment variable.

-- 
Alan Curry