Re: invoking gunzip.exe

[Eli Zaretskii]

> Date: Sat, 28 Apr 2007 17:26:16 -0500
> From: address@hidden (Karl Berry)
> Cc: address@hidden, address@hidden, address@hidden
> 
>     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.

You could have under STRIP_DOT_EXE a different struct:

 #if STRIP_DOT_EXE
   { ".gz", "gzip.exe -d" },
 #else
   { ".gz", "gzip -d" },
 #endif

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

The problem is not when gunzip doesn't work, the problem is when it
doesn't exist (i.e. is not installed).  Without the explicit .exe
suffix, a faithful implementation of popen will be forced to fall back
on the shell when it doesn't find gunzip.exe, and the more stupid
DOS/Windows shells do not return a non-zero status when they fail to
run a command.  Thus, popen itself will think that the command
succeeded, and will be unable to provide useful diagnostics telling
the user that the program was not found.

> Wdyt?

I'd hate to see that improvements paid for in hours of debugging and
engineering are lost in this way.

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

But you can have gunzip a program and comply with this: just don't
make it a symlink to the same executable.  RMS didn't say we must
n-1 programs in a package to shell scripts.