bug#10990: 24.0.94; Uncompressing files

[Dani Moncayo]

>> 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?

But aren't the MSYS utilities native Windows binaries?  Maybe they are
not exactly like the GnuWin32 counterparts, but I currently use them
because they just work and are more convenient to install (they are
bundled as a MinGW package, as you know).

So far, my experience with this setup has been good, but of course I
can change my mind if I find problems in the future.

>> So, in this case, "gunzip" is unnecessary.
>
> Well, evidently, it is necessary ;-)

I'll try to be more accurate: "The functionality offered by gunzip is
a subset of that offered by gzip".

>> 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).

As a curiosity: I've seen that gunzip is implemented in MSYS as a shell script:

 #!/bin/sh
 PATH=${GZIP_BINDIR-'/usr/bin'}:$PATH
 exec gzip -d "$@"

Hence, "gunzip" is unavailable from a native cmd.exe console.

>> 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.

I will use this workaround for now.


Summarizing:

IMO Emacs would be (a bit) better if:
1. The commands for (un)compressing files were configurable (not only
the programs, as in `dired-compress-file-suffixes', but the whole
commands).
2. It was consistent in the uncompression method (when visiting a file
uses one method, and from Dired uses another one).

Needless to say that if you (the maintainers) don't agree, or don't
see a need for this change, you can close this bug report.

In any case, thanks for all your altruistic work.

-- 
Dani Moncayo