Re: invoking gunzip.exe

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[Adding bug-gzip, since the issue of gunzip as a script vs. an executable
belongs there; the thread started here:
http://lists.gnu.org/archive/html/bug-texinfo/2007-04/msg00019.html]

According to Eli Zaretskii on 4/28/2007 9:20 PM:
>> 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.
> 

You have a point here, and there is even precedence for this - coreutils
intentionally ships ls, dir, and vdir as separate executables, rather than
shipping dir and vdir as shell wrappers around ls.  They share the same
source except for a minimal #define that determines the separate default
options between the three.

Another benefit of making gunzip a full-blown executable, instead of a
shell wrapper, is better help output.  Contrast the following, and notice
how poorly gunzip's usage message appears in the simple shell script of
1.3.12:

$ ls --help |head -n1
Usage: ls [OPTION]... [FILE]...
$ dir --help |head -n1
Usage: dir [OPTION]... [FILE]...
$ gzip --help |head -n1
Usage: gzip [OPTION]... [FILE]...
$ gunzip --help |head -n2
Usage: gzip [OPTION]... [FILE]...
Compress or uncompress FILEs (by default, compress FILES in-place).

It is still possible to make a wrapper script give intelligent help
(witness coreutils' groups, wrapping id), but it involves a lot more than
a simple two-liner.  At which point, a simple #define difference in
default options between two similar executables seems more maintainable.

Another benefit of making gunzip a full-blown executable rather than a
shell wrapper is that the startup time is faster (and on cygwin and mingw,
the extra process and time of a shell script wrapper is noticeable).
Uncompressing is a common task, and should not be artificially slowed down
because a shell script is in the mix when a binary could do the job.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGNC+r84KuGfSFAYARAt5yAJ9vDQPQhsWaAkh/oXP/xh5WBLM2jQCgwkv/
H4Q7MrBMTSRpFXk4gT8T/ck=
=8UDu
-----END PGP SIGNATURE-----