GNU bug report logs - #8609
$GZIP doesn't mean what you think it means.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8609 in the body.
You can then email your comments to 8609 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Alan Curry" <pacman-cu <at> kosh.dhis.org>
To: bug-coreutils <at> gnu.org
Subject: $GZIP doesn't mean what you think it means.
Date: Tue, 3 May 2011 02:05:46 -0500 (GMT+5)

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

Message #10 received at 8609-done <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: "Alan Curry" <pacman-cu <at> kosh.dhis.org>
Cc: 8609-done <at> debbugs.gnu.org
Subject: Re: bug#8609: $GZIP doesn't mean what you think it means.
Date: Tue, 03 May 2011 10:13:59 +0200

Alan Curry wrote:
> 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
> %

Thanks for the report.
Here's the fix I'm using in coreutils.
(soon to be in gnulib's bootstrap, too)

From 71cc2504dc05423f10a7a4928cadbbf619cb3780 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering <at> redhat.com>
Date: Tue, 3 May 2011 10:09:20 +0200
Subject: [PATCH] build: avoid bootstrap failure when $GZIP is set

Running "GZIP=-9 ./bootstrap" would fail right away, because the
tool-version-checking code would treat the upper-cased program name
as an environment variable name and if that has a value use the
result as the application name.  That works fine for automake,
autoconf, etc. but not for gzip.
* bootstrap (check_versions): Do not treat $GZIP as a program name.
If defined at all, it is supposed to list gzip options.
Reported by Alan Curry in http://debbugs.gnu.org/8609
---
 bootstrap |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/bootstrap b/bootstrap
index f004ad3..c45ae48 100755
--- a/bootstrap
+++ b/bootstrap
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Print a version string.
-scriptversion=2011-03-03.12; # UTC
+scriptversion=2011-05-03.08; # UTC

 # Bootstrap this package from checked-out sources.

@@ -405,7 +405,10 @@ check_versions() {
     # Honor $APP variables ($TAR, $AUTOCONF, etc.)
     appvar=`echo $app | tr '[a-z]-' '[A-Z]_'`
     test "$appvar" = TAR && appvar=AMTAR
-    eval "app=\${$appvar-$app}"
+    case $appvar in
+        GZIP) ;; # Do not use $GZIP:  it contains gzip options.
+        *) eval "app=\${$appvar-$app}" ;;
+    esac
     inst_ver=$(get_version $app)
     if [ ! "$inst_ver" ]; then
       echo "$me: Error: '$app' not found" >&2
--
1.7.5.141.g791a

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.