emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Emacs-bug-tracker] bug#8609: closed ($GZIP doesn't mean what you think


From: GNU bug Tracking System
Subject: [Emacs-bug-tracker] bug#8609: closed ($GZIP doesn't mean what you think it means.)
Date: Tue, 03 May 2011 08:15:02 +0000

Your message dated Tue, 03 May 2011 10:13:59 +0200
with message-id <address@hidden>
and subject line Re: bug#8609: $GZIP doesn't mean what you think it means.
has caused the GNU bug report #8609,
regarding $GZIP doesn't mean what you think it means.
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
8609: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8609
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- 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



--- End Message ---
--- Begin Message --- 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 <address@hidden>
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


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]