bug-texinfo
[Top][All Lists]
Advanced

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

Re: invoking gunzip.exe


From: Karl Berry
Subject: Re: invoking gunzip.exe
Date: Sat, 28 Apr 2007 17:26:16 -0500

    One way of fixing this that should satisfy all DOS/Windows
    environments without any need for extensive #ifdef'ing is to use
    "gzip.exe -d" instead of "gunzip.exe".

It's not immediately apparent to me how to do that, since "gunzip" is
embedded in a table in info/filesys.c:
static COMPRESSION_ALIST compress_suffixes[] = {
  { ".gz", "gunzip" },
  ...

And then the program name is used on both Unixish and DOSish.

However, looking farther down in filesys.c, I see:

  /* Explicit .exe suffix makes the diagnostics of `popen'
     better on systems where COMMAND.COM is the stock shell.  */
  sprintf (command, "%s%s < %s",
           decompressor, STRIP_DOT_EXE ? ".exe" : "", pathname);

This suggests to me that it would work to simply skip adding the .exe,
that is,

  sprintf (command, "%s < %s", decompressor, pathname);

I guess popen diagnostics would then be suboptimal, but this does not
exactly seem critical to me, since presumably the system is already
pretty badly broken if executing "gunzip" doesn't work.  Wdyt?

    What exactly was wrong with gunzip, fgrep, etc. being programs?)

rms has a penchant for making behavior not depend on program names, so
that one can link to "gunzip" and still get uncompression.  In the User
Interfaces node of the coding standards.

Personally I don't see that it's a problem as long as there are options
to select the desired behavior, e.g., one could do alias mylink="gzip -d"
or write a two-line shell script.  But I gather rms has no interest in
reconsidering this.

karl





reply via email to

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