GNU bug report logs - #10990
24.0.94; Uncompressing files

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 10990 <at> debbugs.gnu.org
Subject: Re: bug#10990: 24.0.94; Uncompressing files
Date: Mon, 12 Mar 2012 19:29:44 +0200

> Date: Mon, 12 Mar 2012 08:46:50 +0100
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> Cc: 10990 <at> debbugs.gnu.org
> 
> In the standard MinGW/MSYS distribution, "gzip" program is designed to
> do both things.  In fact "gzip -h" shows:
> 
>  C:\emacs>gzip -h
>  Usage: gzip [OPTION]... [FILE]...
>  Compress or uncompress FILEs (by default, compress FILES in-place).
>  [...]

Can I persuade you to use the native Windows binaries instead?

> So, in this case, "gunzip" is unnecessary.

Well, evidently, it is necessary ;-)

> BTW, I tried to copy "gzip.exe" as "gunzip.exe" as you suggested, but
> it doesn't work, because Emacs invokes "gunzip" without "-d"
> (obviously), so it doesn't work.

gunzip doesn't need -d, it knows by itself that it needs to
decompress.

No, I guess you have some version of gzip where the maintainers
decided not to change the behavior according to the name of the
program.  Or maybe the MSYS port has a bug in comparing the program
name with "gunzip" (the .exe suffix needs to be stripped).

> A workaround that does work (I've just tested it) is to create a file
> "gunzip.bat" with a single line "gzip -d %1 %2 %3 %4", and store it in
> the same folder as "gzip.exe".

Yep, that's another way of solving this conundrum.

Previous Next

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