bug#10990: 24.0.94; Uncompressing files

bug#10990: 24.0.94; Uncompressing files

[Dani Moncayo]

Hi,

I am on a MS Windows 7 OS.  All the GNU/Unix-like tools that I
currently have/need come from a MinGW/MSYS installation.

I've tried the "Z" command from a dired buffer (to compress a file).
The compression goes well, but when I try to uncompress the same file,
I get the error message: "Searching for program: no such file or
directory, gunzip".

However:
* I can visit the compressed file, which implies an implicit
uncompression.  So if Emacs is able to uncompress the file in this
case, why does it fail in other cases?
* If I open a cmd.exe console and do "gzip -d my_file", the file is
uncompressed without problems.

The docstring of the "Z" command says nothing about customizing the
way of performing the uncompression, and the current way doesn't work
for me.  So I'd like to ask for (a) a better way of finding the
uncompression utility and (b) a way of customizing the command to
perform the uncompression.

TIA.

In GNU Emacs 24.0.94.1 (i386-mingw-nt6.1.7601)
 of 2012-03-07 on DANI-PC
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-gcc (4.6) --enable-checking'


-- 
Dani Moncayo

bug#10990: 24.0.94; Uncompressing files

[Eli Zaretskii]

> Date: Sun, 11 Mar 2012 09:23:11 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> 
> I am on a MS Windows 7 OS.  All the GNU/Unix-like tools that I
> currently have/need come from a MinGW/MSYS installation.
> 
> I've tried the "Z" command from a dired buffer (to compress a file).
> The compression goes well, but when I try to uncompress the same file,
> I get the error message: "Searching for program: no such file or
> directory, gunzip".

Evidently, you don't have gunzip, at least not on PATH.  Or maybe it's
MSYS revenge day: perhaps you do have gunzip, but it's a shell script
or some such.  Anyway, copying gzip.exe into gunzip.exe should be all
you need. 

> However:
> * I can visit the compressed file, which implies an implicit
> uncompression.  So if Emacs is able to uncompress the file in this
> case, why does it fail in other cases?

Visiting compressed files uses "gzip -d", so it doesn't need gunzip.
See lisp/jka-cmpr-hook.el.

> * If I open a cmd.exe console and do "gzip -d my_file", the file is
> uncompressed without problems.

Another evidence to the same effect.

> The docstring of the "Z" command says nothing about customizing the
> way of performing the uncompression, and the current way doesn't work
> for me.  So I'd like to ask for (a) a better way of finding the
> uncompression utility and (b) a way of customizing the command to
> perform the uncompression.

I submit that your system is misconfigured, but of course I won't
object if someone makes a defcustom out of
dired-compress-file-suffixes.

bug#10990: 24.0.94; Uncompressing files

[Dani Moncayo]

On Sun, Mar 11, 2012 at 17:48, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sun, 11 Mar 2012 09:23:11 +0100
>> From: Dani Moncayo <dmoncayo@gmail.com>
>>
>> I am on a MS Windows 7 OS.  All the GNU/Unix-like tools that I
>> currently have/need come from a MinGW/MSYS installation.
>>
>> I've tried the "Z" command from a dired buffer (to compress a file).
>> The compression goes well, but when I try to uncompress the same file,
>> I get the error message: "Searching for program: no such file or
>> directory, gunzip".
>
> Evidently, you don't have gunzip, at least not on PATH.  Or maybe it's
> MSYS revenge day: perhaps you do have gunzip, but it's a shell script
> or some such.  Anyway, copying gzip.exe into gunzip.exe should be all
> you need.

Well, it's obvious that there is no "gunzip" executable visible from
my environment.  I knew that.  And it is also obvious that I don't
need it.  The problem is not that my system is lacking an
uncompression program (I have "gzip -d"), the problem is that Emacs
(a) doesn't know how to invoke it, and (b) doesn't let me tell it how.

>> However:
>> * I can visit the compressed file, which implies an implicit
>> uncompression.  So if Emacs is able to uncompress the file in this
>> case, why does it fail in other cases?
>
> Visiting compressed files uses "gzip -d", so it doesn't need gunzip.
> See lisp/jka-cmpr-hook.el.

Then, why doesn't Emacs use that same method whenever it needs to
uncompress a file?

If Emacs was consistent in this regard and used "gzip -d" whenever it
need to uncompress a file, I would not have had any problem.


>> * If I open a cmd.exe console and do "gzip -d my_file", the file is
>> uncompressed without problems.
>
> Another evidence to the same effect.

An evidence that my system does have a tool for uncompressing files.

>> The docstring of the "Z" command says nothing about customizing the
>> way of performing the uncompression, and the current way doesn't work
>> for me.  So I'd like to ask for (a) a better way of finding the
>> uncompression utility and (b) a way of customizing the command to
>> perform the uncompression.
>
> I submit that your system is misconfigured

???
I showed clearly that my system is capable of uncompressing files
compressed by Emacs.

> but of course I won't
> object if someone makes a defcustom out of
> dired-compress-file-suffixes.


-- 
Dani Moncayo

bug#10990: 24.0.94; Uncompressing files

[Eli Zaretskii]

> Date: Sun, 11 Mar 2012 22:50:06 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 10990@debbugs.gnu.org
> 
> Well, it's obvious that there is no "gunzip" executable visible from
> my environment.  I knew that.  And it is also obvious that I don't
> need it.  The problem is not that my system is lacking an
> uncompression program (I have "gzip -d"), the problem is that Emacs
> (a) doesn't know how to invoke it, and (b) doesn't let me tell it how.

gzip and gunzip are parts of the same package.  It is reasonable to
assume that having one means you also have the other.

But it sounds like you don't actually want to solve your problem, but
rather make some point about big bad Emacs.  Whatever.

> > Visiting compressed files uses "gzip -d", so it doesn't need gunzip.
> > See lisp/jka-cmpr-hook.el.
> 
> Then, why doesn't Emacs use that same method whenever it needs to
> uncompress a file?

Because dired uses a different code which was written by a different
person, I guess.  That code needs a program name, not a shell command,
so "gzip -d" will not do.

> If Emacs was consistent in this regard and used "gzip -d" whenever it
> need to uncompress a file, I would not have had any problem.

I don't see why there should be a consistency in this case.

> > I submit that your system is misconfigured
> 
> ???
> I showed clearly that my system is capable of uncompressing files
> compressed by Emacs.

You have only half of a package installed.

bug#10990: 24.0.94; Uncompressing files

[Dani Moncayo]

>> Well, it's obvious that there is no "gunzip" executable visible from
>> my environment.  I knew that.  And it is also obvious that I don't
>> need it.  The problem is not that my system is lacking an
>> uncompression program (I have "gzip -d"), the problem is that Emacs
>> (a) doesn't know how to invoke it, and (b) doesn't let me tell it how.
>
> gzip and gunzip are parts of the same package.  It is reasonable to
> assume that having one means you also have the other.

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

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

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.

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

> But it sounds like you don't actually want to solve your problem, but
> rather make some point about big bad Emacs.  Whatever.

No.  Evidently I want to solve my problem.

What happens it that, IMHO, the right solution in this case would be
to modify Emacs so that the command for uncompression would be
configurable, because in this case, the default configuration is not
the right one.

>> > Visiting compressed files uses "gzip -d", so it doesn't need gunzip.
>> > See lisp/jka-cmpr-hook.el.
>>
>> Then, why doesn't Emacs use that same method whenever it needs to
>> uncompress a file?
>
> Because dired uses a different code which was written by a different
> person, I guess.  That code needs a program name, not a shell command,
> so "gzip -d" will not do.
>
>> If Emacs was consistent in this regard and used "gzip -d" whenever it
>> need to uncompress a file, I would not have had any problem.
>
> I don't see why there should be a consistency in this case.

Neither I don't see why Emacs use different methods to perform the
same operation (uncompress a file).

>> > I submit that your system is misconfigured
>>
>> ???
>> I showed clearly that my system is capable of uncompressing files
>> compressed by Emacs.
>
> You have only half of a package installed.

No.  I have installed the standard MinGW/MSYS distribution, which has
support for uncompressing files.

-- 
Dani Moncayo

bug#10990: 24.0.94; Uncompressing files

[Juanma Barranquero]

On Mon, Mar 12, 2012 at 08:46, Dani Moncayo <dmoncayo@gmail.com> wrote:

> No.  I have installed the standard MinGW/MSYS distribution, which has
> support for uncompressing files.

And so what? I could write tomorrow two utilities, glurb and deglurb,
to compress and uncompress files, but I wouldn't push Emacs to adapt
to them.

You insist in using MinGW/MSYS as a Unixy-tools-on-Windows package,
but it does things its own way and it's not a supported environment
for Emacs on Windows (some things work, some things don't, as you just
found). And then you complain that it is not supported.

    Juanma

bug#10990: 24.0.94; Uncompressing files

[Eli Zaretskii]

> Date: Mon, 12 Mar 2012 08:46:50 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 10990@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.

bug#10990: 24.0.94; Uncompressing files

[Achim Gratz]

Dani Moncayo <dmoncayo@gmail.com> writes:
> 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.

It does not need to and you don't seem to understand how that is
supposed to work.  If gzip gets invoked as gunzip, then it automatically
infers the "-d" switch.  Which is why usually a symbolic link gunzip ->
gzip is sufficient.  Only that you are running on Windows and Windows
doesn't have symbolic links.  MSys has them, but Windows applications
know nothing about that.

> What happens it that, IMHO, the right solution in this case would be
> to modify Emacs so that the command for uncompression would be
> configurable, because in this case, the default configuration is not
> the right one.

MSys tries to provide a POSIX layer on Windows.  NTemacs tries to
provide it's usual functionality in the absence of such layer.  The two
don't fully mix, in the same way that Cygwin and NTemacs don't.  The
solution is to stay in one world or the other or learn to live with
the roughness around the edges.

> No.  I have installed the standard MinGW/MSYS distribution, which has
> support for uncompressing files.

Well, then look up again where you pick up "gunzip" along your path.
I'm reasonably sure that Windows finds something else instead of the
gunzip.exe you just copied in MSys' /usr/bin (like gunzip, without any
suffix?).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

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

bug#10990: 24.0.94; Uncompressing files

[Stefan Monnier]

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

Agreed.  Patches welcome,


        Stefan

bug#10990: 24.0.94; Uncompressing files

[Achim Gratz]

Achim Gratz <Stromeko@nexgo.de> writes:
> It does not need to and you don't seem to understand how that is
> supposed to work.  If gzip gets invoked as gunzip, then it automatically
> infers the "-d" switch.  Which is why usually a symbolic link gunzip ->
> gzip is sufficient.  Only that you are running on Windows and Windows
> doesn't have symbolic links.  MSys has them, but Windows applications
> know nothing about that.

Come to think of it, I don't think MSys implements symbolic links, so it
most likely uses a shell script to emulate one (again, Windows wouldn't
know what to do with them).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

bug#10990: 24.0.94; Uncompressing files

[Eli Zaretskii]

> Date: Mon, 12 Mar 2012 20:12:14 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 10990@debbugs.gnu.org
> 
> But aren't the MSYS utilities native Windows binaries?

No.  MSYS is a fork of Cygwin, so MSYS binaries are actually much
closer to Cygwin binaries than to native Windows binaries.

bug#10990: 24.0.94; Uncompressing files

[Eli Zaretskii]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Mon, 12 Mar 2012 18:58:59 +0100
> 
> usually a symbolic link gunzip -> gzip is sufficient.  Only that you
> are running on Windows and Windows doesn't have symbolic links.

Actually, starting with Vista, it does.

bug#10990: 24.0.94; Uncompressing files

[Achim Gratz]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Achim Gratz <Stromeko@nexgo.de>
>> 
>> usually a symbolic link gunzip -> gzip is sufficient.  Only that you
>> are running on Windows and Windows doesn't have symbolic links.
>
> Actually, starting with Vista, it does.

I glossed over that detail since they aren't very useful for users
(require elevated administrative privileges to create and change).
Also, see why they are useless for Cygwin:

http://cygwin.com/ml/cygwin/2009-10/msg00756.html

I suspect the same problems would appear if you were to try and use them
from within MSys.  Maybe symbolic links from Windows into Cygwin/MSys
would work, however.  I'll have to try that some time, it would probably
make integration with NTemacs a bit smoother.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

bug#10990: 24.0.94; Uncompressing files

[Marco Centurion]

[-- Attachment #1: Type: text/plain, Size: 535 bytes --]

Given that we already use `gzip` in dired for other formats like `.tar.gz`
and `.tgz`, could we not just replace gunzip with `gzip -d`?  I mean,
even in my (gnu/linux) system `gunzip` is just a script that passes
through to `gzip -d`.

I don't think that change would be a breaking one because we already
assume that `gzip` is present in the system and that `gzip -d`
decompresses files (again, the command for `.tar.gz` is "gzip -dc %i |
tar -xf -").  But if it is considered breaking, we could maybe add an
option to only use gzip?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: bug#10990.patch --]
[-- Type: text/x-patch, Size: 761 bytes --]

diff --git a/lisp/dired-aux.el b/lisp/dired-aux.el
index 0b8c693b29..8e00af8f96 100644
--- a/lisp/dired-aux.el
+++ b/lisp/dired-aux.el
@@ -1137,12 +1137,12 @@ dired-compress-file-suffixes
     ("\\.tar\\.gz\\'" "" "gzip -dc %i | tar -xf -")
     ("\\.tar\\.xz\\'" "" "xz -dc %i | tar -xf -")
     ("\\.tgz\\'" "" "gzip -dc %i | tar -xf -")
-    ("\\.gz\\'" "" "gunzip")
+    ("\\.gz\\'" "" "gzip -d")
     ("\\.lz\\'" "" "lzip -d")
     ("\\.Z\\'" "" "uncompress")
     ;; For .z, try gunzip.  It might be an old gzip file,
     ;; or it might be from compact? pack? (which?) but gunzip handles both.
-    ("\\.z\\'" "" "gunzip")
+    ("\\.z\\'" "" "gzip -d")
     ("\\.dz\\'" "" "dictunzip")
     ("\\.tbz\\'" ".tar" "bunzip2")
     ("\\.bz2\\'" "" "bunzip2")

[-- Attachment #3: Type: text/plain, Size: 90 bytes --]

-- 
Marco Centurion
Unidad de Recursos Informáticos
Facultad de Ingeniería - UdelaR

bug#10990: 24.0.94; Uncompressing files

[Lars Ingebrigtsen]

Marco Centurion <mcenturion@fing.edu.uy> writes:

> Given that we already use `gzip` in dired for other formats like `.tar.gz`
> and `.tgz`, could we not just replace gunzip with `gzip -d`?  I mean,
> even in my (gnu/linux) system `gunzip` is just a script that passes
> through to `gzip -d`.

Makes sense to me; pushed to Emacs 28.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no