After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 583940 - GZIP variable is dangerous
GZIP variable is dangerous
Status: RESOLVED FIXED
Product: gedit-plugins
Classification: Other
Component: General
2.26.x
Other NetBSD
: Normal normal
: ---
Assigned To: Gedit maintainers
Gedit maintainers
Depends on:
Blocks:
 
 
Reported: 2009-05-26 20:37 UTC by Thomas Klausner
Modified: 2019-03-23 20:48 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26



Description Thomas Klausner 2009-05-26 20:37:05 UTC
plugins/taglist/Makefile.am has a line:
    $(GZIP) --best -f $(@:.gz=)

The gzip(1) man page says:
ENVIRONMENT
     If the environment variable GZIP is set, it is parsed as a white-space
     separated list of options handled before any options on the command line.
     Options on the command line will override anything in GZIP.

Thus, if GZIP is e.g. /usr/bin/gzip, this line gets expanded to
    /usr/bin/gzip /usr/bin/gzip --best -f ...
and gzip gzips itself.

The Makefile.in distributed with gedit-2.26.2 shows correct usage in multiple places, e.g.:
    shar $(distdir) | GZIP=$(GZIP_ENV) gzip -c >$(distdir).shar.gz

Please convert plugins/taglist/Makefile.am to that usage as well!
Comment 1 Paolo Borelli 2009-05-27 18:13:51 UTC
however GZIP=$(GZIP_ENV) gzip -c >$(distdir).shar.gz hardcodes the use of 'gzip' instead of using the $(GZIP) executable detected by configure... I wonder if that's ok and we should simply remove the AC_PATH_PROG(GZIP, gzip) from configure.ac
Comment 2 Thomas Klausner 2009-05-27 18:27:35 UTC
Perhaps
GZIP=$(GZIP_ENV) $(GZIP) ...
works?
Comment 3 Steve Frécinaux 2009-05-27 20:40:01 UTC
It might look too obvious to be of use, but what about using AC_PATH_PROG(GZIPBIN, gzip) ?
Comment 4 Paolo Borelli 2009-05-27 20:47:57 UTC
well, what I meant is that if autotools is using plain 'gzip' in stuff it generates we can probably do the same...
Comment 5 Paolo Borelli 2009-08-01 12:23:37 UTC
Sorry for the delay... I took some time to think about it and then forgot :)

I decided to use 

GZIP_ENV = -9

%.tags.gz: %.tags.xml.in $(INTLTOOL_MERGE) $(wildcard $(top_srcdir)/po/*.po)
	LC_ALL=C $(INTLTOOL_MERGE) $(top_srcdir)/po $< $(@:.gz=) -x -u -c $(top_builddir)/po/.intltool-merge-cache
	GZIP=$(GZIP_ENV) gzip -c $(@:.gz=) >$@


Since as I said autotools themselves seem to rely on gzip being available, so no need to detect it