-----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 [EMAIL PROTECTED] -----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-----
